Does the std module use the same .a/.so as as headers? How does that work
with headers and -fno-exception, or does that have to be taken care of
today by the user?

The other question is if the interface goes in include/ or share/libc++ for
FHS like layout, and then is it possible to deploy a commonly used BMI into
lib or libexec.

FHS implicitly assumes a coherent installation within a $prefix, which also
means that ABI affecting flags are fixed, so system compilers ought to be
able to at least pre build the system std modules.

On Sun, Dec 10, 2023, 08:11 Mark de Wever via SG15 <sg15_at_[hidden]>
wrote:

> Hi Michael,
>
> Thanks for scheduling a meeting.
>
> On Wed, Dec 06, 2023 at 11:38:30PM -0800, Michael Spencer via SG15 wrote:
> > We've had previous discussion on this (
> > https://lists.isocpp.org/sg15/2023/07/1971.php), and recently libc++ has
> > been asked to start vending its std.cppm file (
> > https://github.com/llvm/llvm-project/issues/73089).
> >
> > I'm going to schedule a meeting to discuss the specific issue of where
> this
> > file should live and what it should be called for Unix-like systems, as
> now
> > build systems also need to care where this file lives.
>
> I strongly suspect that Standard libraries need to store additional
> information so build systems are able to build the BMI from std.cppm.
> Otherwise build systems need to hard-code this information in their
> tools.
>
> > I expect the outcome of this meeting to be a consensus of how this
> > should be handled, and the intent to document it as part of the
> > Ecosystem IS at a future point.
>
> +1
>
> Here is a short overview of the current state of modules in libc++ and
> what open questions I have to provide build systems with sufficient
> information to build the standard library modules.
>
> At the moment libc++ provides both the std and the std.compat module as
> an experimental feature. The modules are not installed so users have to
> manually add them in their CMake project [1].
>
> Currently libc++ has a std.cppm, a std.compat.cppm, and an .inc file for
> every header. The std.compat module is independent of the std module,
> however I'd like std.compat to use the std module as basis.
>
> In order to build the module certain module specific compiler flags are
> required. For example, -Wno-reserved-module-identifier is required by
> Clang to build a module with the reserved name std.
> Other flags are added depending on the configuration options vendors use
> to build libc++. For example, building with exceptions disabled requires
> -fno-exceptions as module build flag.
> This information is currently stored in a CMakeLists.txt that is
> generated in the lib++ build process [2]. This CMakeLists.txt is a
> temporary solution to bootstrap building modules in libc++, once build
> systems have proper support I want to remove this file.
>
> The questions I have:
>
> Where should we install the module files (.*cppm and *.inc)?
>
> How can we provide build systems with the compiler flags and files needed
> to build the modules? MSVC STL currently provides a module.json [3],
> should we use that as a basis?
>
> Do we need to provide dependency information between the std.compat and
> std module? MSVC STL does not have that information in their JSON, but
> std.compat exports the std module.
>
>
> [1] https://libcxx.llvm.org/Modules.html#using-in-external-projects
> [2]
> https://github.com/llvm/llvm-project/blob/main/libcxx/modules/CMakeLists.txt.in
> [3] https://github.com/microsoft/STL/blob/main/stl/modules/modules.json
>
>
> Cheers,
> Mark de Wever
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>