Hi, I am here after a lot of scouring the internet due to my own clang tool failing when CMake updated to 3.28. The root of the issue is related to the @foo.modmap files as discussed here, but I think the reasons discussed so far miss the cause.
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.
The problem then is that CMake generates a @foo.modmap file during compilation for each .cc file that it builds. The file is not created as a result of configure, and it’s not left behind after compilation, only the .obj file is left behind.
So when I run a clang tool against the command line specified in compile_commands.json, it fails due to the @foo.modmap file not existing. AFAICT the command that CMake writes into the compile_commands.json is incorrect, since it’s pointing to a file (the modmap file) which does not actually exist (outside of cmake doing compilation which is not what compile_commands.json is for).
This renders the compile_commands.json broken, and requires tools to strip out the @foo.modmap argument in order to run the clang tool against the command line arguments in the compile_commands.json file. This will work until code actually uses modules at which point it will fall over again, as the root issue is unresolved: that the command line in the compile_commands.json file as generated by CMake is not able to independently reproduce the compilation step.
FTR, I am using CMake 3.28.1, and this issue occurs on Windows and Linux, targeting Clang and MSVC. 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.
My debugging FWIW: Subdoc fails with missing modmap files · Issue #437 · chromium/subspace · GitHub