Generate compile_commands.json for clangd

[s-sajid-ali]

compile_commands.json is used by clangd LSP to interpret the source files

[s-sajid-ali]

Is placing this in the source directory best practice?

Per the docs:

We first check for a compilation database in the directory containing the source file,
and then walk up into parent directories until we find one.

[ax3l]

Clang on Windows seems happy but MSVC is not yet:

     4>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(248,5): error MSB8066: Custom build for 'D:\a\impactx\impactx\build\CMakeFiles\c134c98d71a9573b76308dc0d94c59ed\copy-compile-commands.rule;D:\a\impactx\impactx\CMakeLists.txt' exited with code 1. [D:\a\impactx\impactx\build\copy-compile-commands.vcxproj]

Actually, how does this handle MultiConfig generators?
https://cmake.org/cmake/help/latest/prop_gbl/GENERATOR_IS_MULTI_CONFIG.html

[ax3l]

This has to be guarded for all build generators that are not GNUmake or Ninja:
https://cmake.org/cmake/help/latest/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html

Note

This option is implemented only by Makefile Generators and Ninja Generators. It is ignored on other generators.

This option currently does not work well in combination with the UNITY_BUILD target property or the CMAKE_UNITY_BUILD variable.

[s-sajid-ali]

Added a guard to only generate compile_commands.json for Unix Makefiles and Ninja generators.

[ax3l]

Is placing this in the source directory best practice?

Per the docs:

We first check for a compilation database in the directory containing the source file,
and then walk up into parent directories until we find one.

I wonder if they mean they also look recursively into directories inside source, e.g., in build/.

Generally, I do not see how this can work with multi-config generators at all - every config needs its own compile_commands.json.

Clion's IDE solves this a bit smarter, they are aware of the build configs, generate a file in the respective build directory and run clangd on that. Is there a way in your IDE to configure this equally? Which IDE are you using? Or did you configure clangd manually to work with your toolchain?

[s-sajid-ali]

Generally, I do not see how this can work with multi-config generators at all - every config needs its own compile_commands.json.

Upon further thought, I agree that placing it in the build directory is a better solution than placing it in the source directory. I've removed the command that copies it to the source directory.

[s-sajid-ali]

Which IDE are you using? Or did you configure clangd manually to work with your toolchain?

I'm using neovim which comes with a built-in LSP client that I've configured to use clangd.

Clion's IDE solves this a bit smarter, they are aware of the build configs, generate a file in the respective build directory and run clangd on that. Is there a way in your IDE to configure this equally?

Maybe there is, but I'm not aware of it.

If we place compile_commands.json only in the build directory, the only restriction would be to browse from the build directory to get the LSP to work. Sometimes if the project is built with different options turned on/off and there are #ifdefs, the code that gets highlighted changes with the build configuration. Hence it might be preferable to open the editor from the build directory rather than the source directory.