Hi Mark,

> On 2 Jul 2023, at 16:41, Mark de Wever via SG15 <sg15_at_[hidden]> wrote:
>
> I'm a libc++ developer working on implementing the std and the
> std.compat module. I have an experimental version of the std module [1].
> Using the module requires manually building the BMI using the files in
> the local libc++ build directory. This works for early adaptors, but is
> not a solution that can be used in production.
>
> There was an discussion about the installation location on LLVM's
> discourse [2]. There it has been suggested to discuss this in SG15. I
> spoke with Louis Dionne, the maintainer of libc++. He spoke with Michael
> Spencer and it indeed seems in the purview of SG15 to discuss this.
> Louis asked me to send an email to the reflector to give more
> information for a discussion during a telecon.
>
> The goal is to find a good installation directory for (standard) library
> module sources so they can be used by build systems to build the
> required BMIs. This means the library should provide the information
> needed for build systems. There is a p1689 format for modules, which
> seems good starting point for supplying this information.
> With this information users can import the std(.compat) module in their
> projects and it works out of the box, just like including standard
> headers and linking against the standard library.
>
> MSVC has the files std.ixx, std.compat.ixx, and modules.json in their
> source tree. I've no experience with MSVC and what is required to build
> BMIs from these source files.
>
> Libc++ has std.cppm, std/<header>.cppm for every header, and a
> CMakeLists.txt. In order to build the BMI clang needs to use special
> build flags. For example, -Wno-reserved-module-identifier is needed to
> allow building modules with implementation reserved names. AFAIK
> specifying build flags is not possible in the p1689 format without
> vendor extensions.
>
> 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>/
>
> For example, Apple uses ${SDKROOT} as ${PREFIX} where it's an empty
> string on Linux systems.
>
> The <library> is the name of the library where every name starting with
> the library name is reserved. Some examples:
>
> ${PREFIX}/usr/share/c++/modules/libc++/v1/std.cppm
> ${PREFIX}/usr/share/c++/modules/libc++/v1/std.compat.cppm
>
> ${PREFIX}/usr/share/c++/modules/libstdc++/14/std.cppm
> ${PREFIX}/usr/share/c++/modules/libstdc++/14/std.compat.cppm
>
> ${PREFIX}/usr/share/c++/modules/qt/core.cppm
> ${PREFIX}/usr/share/c++/modules/qt/network.cppm
>
> ${PREFIX}/usr/share/c++/modules/boost181/boost.cppm
> ${PREFIX}/usr/share/c++/modules/boost182/boost.cppm
>
> In the latter case the boost181 and boost182 belong to the boost
> library namespace.
>
> The proposed path seems not a good path for Windows. I hope the
> Microsoft developers have a suggestion. Would it be possible for other
> libraries to match with MSVC STL does?
>
> The things I would like to discuss are:
> - Are we happy with the proposed locations on non-Windows systems?
> - What would be a good location on Windows?
> - What information do build system vendors need to turn the sources into
> BMI files and how is this information provided.

It seems, to me, that there are two parts to this:

1) The layout of the sources for interfaces and implementations

  - this seems like something we can work on with the suggestions above (and in other responses to the mail).

2) Where the layout of (1) is rooted.

This seems something that the wider “implementation” (including things outside of any specific toolchain) will control. Imagining variable situations like the Apple SDKs mentioned above, sysroots for cross compilers, and differing installation patterns for various OSs; there are many permutations.

Perhaps it would be more successful if we standardised a way to obtain the root position from the active toolchain (i.e. analogous to existing queries to compilers to report their sysroot path). That still requires the wider community to agree on (1).

Assuming we are going to compile these sources, we must have a toolchain we can execute, so it is reasonable to ask for a standard tool query.

Iain