On Fri, Jul 07, 2023 at 09:41:09AM +0200, Boris Kolpackov wrote:
> 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.

I agree this would make it easy to find the modules. My concern with
reusing the include directory for modules is that it may lead to users
writing code like:

  #include <std.cppm>

Which then does not work as expected. I rather have a solution where the
user can't do the wrong thing by accident.

> > - 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

Thanks for the info.

Cheers,
Mark