Starting with LLVM-18 libc++ is able to install the sources of the C++23 std and std.compat module. Since module support in libc++ is still experimental, this is not enabled by default. It can be enabled by configuring CMake with the option -DLIBCXX_INSTALL_MODULES=ON. The installation location can be configured with -DLIBCXX_INSTALL_MODULE_DIR=<path>. The default location is ${PREFIX}/share/libc++/v1. In the libc++ library installation directory there will be a file named modules.json, This file is intended for build systems to determine how to build the modules from the provided sources.
It would be great when vendors can enable this as an optional feature for their users. For example, in a separate package. Having this available allows build system vendors to start supporting building the std and std.compat module.
PS: All major Standard library vendors agreed to make the std and std.compat module available in C++20.
The std module, std.compat module, and their modules.json could be delivered in separate packages, though I expect it could be a little more complicated to do that.
Onr implicit requirement of these files is that they would allow users of libc++ to parse the std and std.compat interfaces in a way that is parse compatible with the way libc++ parsed the same entities. Parse compatibility is has some overlap with ABI compatibility, but there are ABI unimportant entities that are important for parsing, such as ABI compatible instrumentation in inline entities. And there are ABI important entities that are irrelevant for parsing APIs, especially entities that are implementation details to anything except perhaps a linker.
Point being, there will be relatively high coupling between libc++ binary files, the C++ module files, and the modules.json files that define flags, dependencies, and other information needed to parse those modules. It is theoretically possible to split those files to other packages, but care would have to be taken to make sure both packages are maintained as a matching set. I would guess that keeping everything in the same package would be an attractive choice, though perhaps there are benefits to multiple packages that make the added complexity worth it.
The files are additive, so I wouldn’t expect any existing usage to break due to enabling the std and std.expected modules.
Though as far as I know, nobody has used these mechanisms seriously yet, so there’s some wisdom to initially releasing these features as obviously experimental and opt-in. There’s some chance we learn about large or small defects in these designs when they get serious use.
No downsides for enabling it by default since it only tries to install 3 text files: std.cppm, std.compat.cppm and modules.json.
I think the reason why libc++ don’t enable it by default is to follow the libc++'s policy. It is still experimental. And libc++ don’t hope users to misunderstand this.