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.

[1] https://libcxx.llvm.org/Modules.html
[2] https://discourse.llvm.org/t/rfc-about-the-default-location-for-std-modules/69191

Cheers,
Mark