Date: Sun, 10 Dec 2023 14:11:50 +0100
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
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
Received on 2023-12-10 13:11:55