[m-rev.] for post-commit review: document the rest of the PROPOSED search options

[Julien Fischer]

On Sat, 21 Dec 2024 at 16:29, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
> On Sat, 21 Dec 2024 16:17:13 +1100, Julien Fischer <jfischer at opturion.com> wrote:
> > > + at c @sp 1
> > > + at c @item --c-include-dir-same-workspace @var{workspace_directory}
> > > + at c @itemx --c-inc-dir-same-ws @var{workspace_directory}
> > > + at c @sp 1
> > > + at c @itemx --c-include-dir-independent-workspace @var{workspace_directory}
> > > + at c @itemx --c-incl-dir-indep-ws @var{workspace_directory}
> > > + at c @sp 1
> > > + at c @itemx --c-include-dir-installed-library @var{install_directory}
> > > + at c @itemx --c-incl-dir-installed-lib @var{install_directory}
> >
> > For C header files specifically, there's an extra wrinkle. The existing
> > --c-include-dir option is also (ab)used to get the Mercury compiler to
> > tell the C compiler where to find header files for C libraries that are
> > used by a Mercury program. I think we probably want to keep it around
> > for that purpose, since:
> >
> >    --c-include-dir /path/to/some/c/lib
> >
> > is less cumbersome than:
> >
> >    --c-flags "-I /path/to/some/c-lib"

Another potential reason to prefer the former is that it avoids having
to specify
what C compiler option is used to tell the C compiler where to search
(which could
potentially vary between C compilers -- the Mercury compiler can
select the correct
option based on the fact that it knows the C compiler type.)

> OK. It would seem simplest to add, after the three options above,
> a fourth, named --c-include-dir-X where X may be "external" or
> "non-mercury" or something like that, to serve that purpose.
> The directories named by that option would, or at least should,
> contain only .h files, not .mh or .mih files, though we wouldn't want
> to even try to enforce that.

Agreed.

> Any preferences for what X should be?

"external" seems fine.

Julien.