On Sun, Jul 09, 2023 at 14:00:11 +0200, Mark de Wever wrote:
> 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?

CMake will provide a uniform interface, but a way to extract the needed
info from the toolchain would be great :) . That is, CMake will concern
itself with the CMake bits, but metadata from the toolchain about what
to fill in would be great. MSVC is shipping a `modules.json` file. I'd
be fine with building on that (i.e., the flag needed to silence warnings
would be nice to have in there somewhere).

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

It's kind of necessary to have modules be useful in the kinds of
projects CMake ends up supporting (e.g., mixed standards and flags).

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

I've heard/seen `$prefix/include`, `$prefix/modules`, `$prefix/lib`, and
`$prefix/share`. I think that's the breadth of the options here (I don't
think anyone is going to argue for `$prefix/bin`, `$prefix/var`, or
`$prefix/src`…). Another forum for discussion can be here once we look
to include other interested groups:

    https://github.com/isocpp/pkg-fmt/discussions

Prior art from the Fortran world is that module files (akin to BMIs) are
just dumped into an `include` search path and searched for that way even
though they are also very compiler-specific.

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

I'm not so concerned with the SONAME itself (that's really something for
the linker and runtime loader to figure out), but more "how do we find
the modules corresponding with library X?". If the directory name
doesn't correlate with the library (or come from some metadata file that
is found first), things are going to be just continue the `-I` dumping
ground we have today where we have a bunch of `libfoo.so` files, a
directory of `include` files and no idea what goes with what.

--Ben