support commands in settings

For proper CMake support we would need "clangd.arguments": [ "--compile-commands-dir=${command:cmake.launchTargetDirectory}" ]. https://github.com/microsoft/vscode-cmake-tools/issues/654

Problem is that invoking commands is async so you can’t just add this in config.ts:

const cmdPrefix = 'command:';
if (name.startsWith(cmdPrefix))
    return await vscode.commands.executeCommand(name.substr(cmdPrefix.length));

Btw, looks like the relevant vscode feature request is https://github.com/microsoft/vscode/issues/46471.

[abdes]

he biggest problem here is there’s no principled way to even figure out a project root in the absence of a compile_commands.json. We can make use of other heuristics like existence of …

Please note that in a multi-config build environment the problem is not the project root, but rather the build output root for each config.

For example, in my case (cmake + clangd + vscode + cmake-tools), I definitely want my build to be out of source and each build config in its separate build tree (e.g. windows, linux, dev, release, valgrind, etc…).

The one responsible for generating the compilation database is cmake. CMake knows everything about the project, its source, its build output, etc…

The one that invokes cmake is cmake-tools, which knows about the CMakePresets.json which has the source dir, build, dir, preset name, and many more info about the presets. My understanding is that the whole point from this issue is to use such info through a substitution with command in vscode settings.json.

The one who uses compiler_commands.json is clangd and clangd has no idea where cmake is putting that file, and the settings in vscode are so limited that we can only (right now) hardcode a directory for clangd to look into.

So at the end of the day, imho, it’s not really clangd’s responsibility to figure out where cmake puts its babies. Inside vscode it’s just a pity that there is no such seamless integration happening between cmake, cmake-tools, clangd and vscode.

Outside of vscode, I don’t know whether there is a universal solution for this problem, but a good compromise is when clangd is working in a cmake environment and that environment has a CMakePresets.json. That presets file could be used by clangd to get a lot of info. That’s exactly how Visual Studio for example integrates cmake now…

To conclude, I really appreciate what you guys are doing and it’s just so great to have clangd in vscode that I wanted it to be not just great, but perfect 😃

[ahfakt]

Do developers think about to implement ${command:…} substitution? “cmake.copyCompileCommands” alternative works but having to use it is still uncomfortable.