Mark de Wever via SG15 <sg15_at_[hidden]> writes:

> When the standard libraries have a good location it seems natural that
> other libraries want to use a similar location. It would be good to have
> a uniform way to store module information, which then can be used by
> build systems to build the required BMI files.
>
> The suggestion on LLVM's discourse for the path would be
>
> ${PREFIX}/usr/share/c++/modules/<library>/

I would suggest reusing the header installation location (i.e.,
/usr/include/<library>/) for this. We did a bit of thinking on
this for modules support in build2 and that's what we have
settled on. This approach has the following advantages:

1. This location is already defined, including for Windows/MSVC.

2. The module interface unit matches well to the header in the
   "kind of file" terms (source code, architecture-independent,
   goes to the -dev/-devel package, etc) which will make many
   "downstream" lives esier.

3. In case some build systems need to search for module interfaces
   of installed libraries (see more on this below), the existing -I
   mechanism (however flawed) can be reused instead of reinventing
   another (inevitabely equally flawed), "search paths" mechanism.

> - What information do build system vendors need to turn the sources into
> BMI files and how is this information provided.

In build2 we are using the pkg-config format (which supports arbitrary
variables) to provide the mapping of module names to module interface
files (besides other things) to avoid "search paths". For details see:

https://build2.org/blog/build2-cxx20-modules-gcc.xhtml#libraries