On Thu, Jul 06, 2023 at 07:00:45PM -0400, Ben Boeckel wrote:
> On Sun, Jul 02, 2023 at 17:41:29 +0200, Mark de Wever via SG15 wrote:
> > 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.
>
> Nor is it intended to. Note that extensions are, de jure, ignorable. In
> CMake terms, this would be part of the relevant `CMake::CXX23` (or
> whatever color that bikeshed gets painted) target that references the
> modules. Something like:
>
> add_library(CMake::CXX23 IMPORTED INTERFACE)
> target_compile_options(CMake::CXX23 PRIVATE -Wno-reserved-module-identifier)
> target_sources(CMake::CXX23 INTERFACE FILE_SET TYPE CXX_MODULES FILES std.cppm std.compat.cppm BASE_DIRS …)

This information is it intended that libc++ provides that or will that
be part of CMake Clang module?

> Then (as I imagine it at least), CMake would see "oh, you use C++23 and
> haven't disabled all modules support, so you implicitly link to
> CMake::CXX23" and the support for modules on IMPORTED targets handles
> the BMI generation. The WIP MR that enables this and that I plan to
> polish later this month is here:
>
> https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8535
>
> The modules would be scanned (to gather module dependency information)
> and BMI'd as needed by consumers.

This sounds interesting to have in CMake.

> > 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>/
>
> Has the FHS group been contacted about this? I have an affinity towards
> `/usr/lib` instead as they are tied to compiled artifacts in that while
> the modules may need compiled umpteen ways for BMI usage, there's still
> only one `libc++` they're associated with (my motivating thoughts are
> that installing multiple libc++ libraries shouldn't conflict under
> `/usr/share`).
>
> FHS mailing list info:
>
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch07.html#theFhsMailingList

I haven't contacted this group. I think it's better to first get a
feeling what SG15 wants before contacting this group.

> > For example, Apple uses ${SDKROOT} as ${PREFIX} where it's an empty
> > string on Linux systems.
>
> A nitpick, but `${PREFIX}` usually handles the `/usr` on Unix platforms
> (e.g., `/usr/local` is impossible with the proposed pattern as-is).
> Apple can do whatever they do today to reroot under the SDK as they do
> for everything else that gets installed (I suspect there's some DESTDIR
> and longer PREFIX settings, but that's just a guess). The SDKs are all
> relocatable anyways, so there's not really a set place beyond "what does
> the compiler think the SDK root is?" whether that be set via
> `xcodeselect` or `DEVELOPER_DIR`).

Good point, thanks.

> > 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.
>
> Is there any correlation with SONAME or is it more about the `.so`
> linker file name? Boost has…complex library naming rules as it is and is
> why I think there's interest in storing (at least a pointer to the
> module files) closer to the libraries themselves.

In the current proposal there is not. If this directory contains a
JSON file with tooling information the SONAME can be stored in that
file.

Cheers,
Mark