We use CMake as our build automation tool (we develop for Cortex-M microcontrollers and a like).
Currently we are working on setting up clangd to work properly in our IDE, but due to the cross-compilation we will likely want to make a manipulated copy of the compilation database that Ninja creates.
Therefor I’m looking for an easy way to always run a tool/script after the generation phase, so that we can make sure that the manipulated “copy” is always up to date.
Does CMake offer any hook?
Of course I can write a wrapper script for CMake, but I think that will be annoying to integrate in Visual Studio Code and to also use in our CI. If CMake offers something for this, that would of course be preferred.
You can effectively create a hook that runs at the end of the configuration phase, but not at the end of the generation phase. However, even the hook at the end of the configuration phase won’t be late enough, because it will run before the CMakeCache.txt or a compile_commands.json is written. If you do really need to modify the compile_commands.json that CMake generates, then your idea of a wrapper around the cmake executable is probably going to be your path forward. Personally, I’d try to avoid having to modify compile_commands.json, but that might not be a choice you have with your set of requirements.
This by far not the first request (disclaimer: one of them’s mine) for supporting a post-generation hook. Wrappers are cumbersome. Would CMake developers be willing to re-consider the policy of “we don’t want to support user-defined post-generation processing,” at least if it came with a big warning “It may break if we change the way we produce output, you’ve been warned”?
I understand projects “in the wild” need to cope with being processed by unexpected versions of CMake, but CMake is also used by companies for in-house software development. There, environments (including CMake version) are much more controlled, so adapting to a change in CMake’s output behaviour is easier. At the same time, special requirements which would benefit from a post-generation step are much more likely to exist (as follows from the same existence of the usually quite bespoke environment).
I can accept the answer remaining “no,” but I thought I’d at least raise the question again.
due to the cross-compilation we will likely want to make a manipulated copy of the compilation database that Ninja creates.
could you expand on this? I’ve been using compile_commands.json with clangd when cross-compiling just fine. with some tinkering it can also work with regular visual studio (not code)
Main issue we have seen is that clangd struggles to determine the correct include paths for header files, if no source file has previously been opened that included it (to “prime” its cache).
One of the suggestions given in the clangd community was expanding the compilation database to also include entries for header files, therefore explicitly setting any include paths it may need.
Since we explicitly set the dependencies on all our targets, we can use the CMake File API to get the data we need to construct these entries.