How to control the location of the c++20 Binary Module Interface (BMI) output directory?

[ben.boeckel (Ben Boeckel (Kitware))]

@danakj

Nibble Stew: The road to hell is paved with good intentions and C++ modules explains (the author is not a fan, but please don’t focus on that here) what is going on during compilation with CMake now and what the @foo.modmap files are. I could not find any other docs that explained it.

Please read the Reddit comments on that blog post. I do need to write up docs on how CMake implements modules. It’s on my list.

@danakj

If CMake is wedded to the idea of using a modmap file during compilation, it needs to write them all to disk at the same time that it generates the compile_commands.json.

Then it will need to wait until the build is complete. The .modmap files cannot be made at generate time without CMake having to regenerate the build on every .modmap-using source file. At that point, the file is the same as made during configure and the .modmap files are present for use by any compile_commands.json-using tool. Note that there is also no safe place in the graph to place a command to generate compile_commands.json because:

• targets may be EXCLUDE_ALL and not build via the default target and still reference non-existent files
• if it needs updated (e.g., after a re-configure, it is out-of-date until regenerated)

Note that this has always been an issue with build-generated sources or headers. There is a plan to solve this part of the problem in 2024 with something like a generated-sources target (name and details TBD) to generate all sources. A similar target to make .modmap files present would also be something that could be done at the same time.

@danakj

This will work until code actually uses modules at which point it will fall over again

If the projects do not actually use modules, they can set CMAKE_CXX_SCAN_FOR_MODULES to 0 to disable scanning (and therefore .modmap file usage).

Note that it will be the least of your worries as the BMIs that are made during the build will be compiler-specific and your tool will (likely) need to generate its own BMIs in order to perform the import statements in the analyzed. There are plans for generating enough information for tools to be able to generate their own BMIs in 2024 as well (future work can let CMake drive the tool to make these BMIs, but that is likely farther out).