David Blaikie via SG15 <sg15_at_[hidden]> writes:

> (I hope this isn't too derailing... )
>
> Seems like we have, broadly:
>
> 1) Lookup relative to/related to the include/module source search path

I would strongly advocate against adding any sort of search paths
for modules.

I am not sure what other's experience is with header search paths
(-I), but ours in build2 strongly suggests that it's probably the
most broken part of the C/C++ compilation model, especially when
it comes to auto-generated headers. Specifically:

1. Compilers have built-in header search paths which means build
   systems have to figure out what they are, which is invariably
   done in a hackish, compiler-specific manner.

2. The search paths are sensitive to order which makes using
   independently-developed libraries in the same build brittle,
   with wrong headers being found in unexpected locations.

   The practice of including headers with a library-specific
   directory prefix (e.g., <libfoo/utility.hpp>) is unfortunately
   nowhere near universal (even this committee members, who must
   know better, do not always follow it).

3. If an auto-generated header does not exist, the compiler may
   find and include an identically-named but unrelated header that
   is found in one of the further -I directories.

   Including an outdated or wrong header may trigger a fatal
   preprocessor error before the build system has a chance to
   correct the situation (e.g., re-generate the header in the
   expected location).

   See P1842[1] for further detail on this point and what could be
   done about it.

Please, let's not repeat the same mistake again.

[1] https://wg21.link/P1842