Setup compile commands directory for the clangd extension #210
Conversation
|
Note that the clangd race condition can be reproduced by creating the following shell script: #!/bin/sh
sleep 10
clangd "$@"And then setting the I do not think we should be concerned with bugs in proper command handling / queuing in third-party extensions. |
src/extension.ts
Outdated
| const conf2 = vscode.workspace.getConfiguration("clangd"); | ||
| conf2.update("arguments", [`--compile-commands-dir=${buildDir}`], vscode.ConfigurationTarget.Workspace); |
There was a problem hiding this comment.
What happens if you have clangd.arguments defined in your user settings and then this runs?
There was a problem hiding this comment.
The workspace settings seem to override the user settings. I have both defined, but only the workspace provided argument is present in the ps aux output.
There was a problem hiding this comment.
The downside is we override user settings that could be defining other stuff than the compile commands. Maybe we should wait for clangd to add a dedicated setting for this?
BTW, if someone knows a better trick than a workspace setting for communicating the path to compile_commands.json to other extensions, that would be great. One big downside of this approach is it modifies .vscode/settings.json in user's source tree, and some projects does track that file in git...
There was a problem hiding this comment.
Maybe we should wait for clangd to add a dedicated setting for this?
The PR for vscode-clangd is currently more than a month old, with zero comments so far. And it's not even that complicated... Currently I can't see it moving forward in a reasonable timeframe.
BTW, if someone knows a better trick than a workspace setting for communicating the path to compile_commands.json to other extensions, that would be great.
In theory, extensions should be able to expose their internal API to other extensions by returning data from the activation function.
https://code.visualstudio.com/api/references/vscode-api#extensions
One big downside of this approach is it modifies
.vscode/settings.jsonin user's source tree, and some projects does track that file in git...
True.
There was a problem hiding this comment.
compile_commands.json to other extensions, that would be great. One big downside of this approach is it modifies .vscode/settings.json in user's source tree, and some projects does track that file in git...
I actually hate this about the Meson extension. For instance, I have "C_Cpp.intelliSenseEngine": "disabled",, so I don't even use the compilation database for the extension. We should check this setting to not edit the file.
I've also thought about just adding a setting to this extension whether or not to auto setup other extensions. It is really freaking annoying!
There was a problem hiding this comment.
I've also thought about just adding a setting to this extension whether or not to auto setup other extensions. It is really freaking annoying!
I made this configurable.
There was a problem hiding this comment.
@wolfpld I think we could be smarter here. If we can read the current setting, we can then check if the compile commands dir is already set. If not set, extend the current setting with the arguments to set the compile commands dir.
Something like this?
let args = undefined;
const wanted = `--compile-commands-dir=${buildDir}`;
const current = conf.get("clangd.arguments");
if (current && Array.isArray(current)) {
// if wanted is already in current, leave args undefined to prevent a config update
if (!current.includes(wanted)) {
const found = current.findIndex((arg) => arg.startsWith("--compile-commands-dir="));
if (found !== -1) {
current[found] = wanted;
args = current;
} else {
args = [...current, wanted];
}
}
} else {
args = [wanted];
}
if (args) {
conf
.update("clangd.arguments", args, vscode.ConfigurationTarget.Workspace)
.then(
() => vscode.commands.executeCommand("clangd.restart"),
() => {},
);
}There was a problem hiding this comment.
Perhaps. I would need to test with my setup.
// Clangd
"clangd.arguments": [
"--all-scopes-completion=false",
"--clang-tidy",
"--completion-style=bundled",
"--enable-config",
"--header-insertion=never",
"--header-insertion-decorators",
"--pch-storage=disk",
],
FWIW, the clangd extension seems to do a recursive search for compilation databases.
There was a problem hiding this comment.
FWIW, the clangd extension seems to do a recursive search for compilation databases.
It won't pick up the database if I don't change the default builddir to build in the meson extension (without this PR).
I also had some very unfun experience trying to figure out why the include path changes I made in meson.build were not picked up by clangd, while the project compiled just fine. It turned out that I had two build dirs, build and builddir. Clangd was reading build while the meson extension was updating builddir.
There was a problem hiding this comment.
Perhaps. I would need to test with my setup.
Ok, I pushed it. Note that the clangd.arguments getter is not scoped to the workspace, so it will pick up user settings if any are set, and the workspace settings are empty.
package.json
Outdated
| "type": "boolean", | ||
| "default": true, | ||
| "description": "Setup the rust-analyzer extension to work with Meson." | ||
| }, |
There was a problem hiding this comment.
I'm not sure we need a specific setting for each of them. What about a single boolean to disable modifying user settings at all? My use-case here is for projects that commit .vscode/settings.json into git, they don't want meson extension to make a diff in that file all the time.
There was a problem hiding this comment.
My thoughts were that you may want to have both the C++ and clangd extensions installed, but you may want to use only one of them for a particular project. There are also other considerations, for example, you may be fine with updating the C++ extension configuration, which goes through a dedicated setting, but you may not be fine with modifying the clangd arguments list, which is passed to an external executable.
I don't have a strong preference for one option or the other, but with the changes @tristan957 made, we explicitly tell users that we have support for this and that extension. This would go away if there was only one option to choose from.
What are your thoughts on this?
There was a problem hiding this comment.
See latest master. We offer a boolean value or an array so all good!
|
Can you rebase this on main. I basically cherry-picked what you had. |
|
Rebased. |
|
Sorry for forcing another rebase on you :( |
|
Rebased. |
|
Can you squash the commits? |
|
Done. |
|
Are there any remaining issues that would block the merge? |
|
I just haven't gotten a chance to review and test. |
|
To consider: The CMake VS Code extension solves this problem by copying
This becomes more problematic if you have a multi-root workspace. In this case, the roots are enumerated in the same file that contains the settings, so you can't even choose not to include them in the repository. Unfortunately, I won't be working on this anymore due to how things like mesonbuild/meson#5859 are handled. Meson is basically useless if you want to work on Windows, or if you want to configure the build directory from an IDE like VS Code, or really do anything outside of the one and only allowed use case. |
Because nobody who works on Meson uses Windows, or Mac for that matter, on a regular basis. If you want better Windows support, you need to step up. There are exactly 3 people who get paid to work on Meson that I know of, and that is only part of the time. None of the companies paying those people have a vested interest in Meson on Windows, or if they do, it works well enough for them.
This extension is best effort, and is all volunteer work. Please provide more ideas on how this experience can be better.
What is this use case? |
|
I have linked a PR where @xclaesse explains the problems quite well and proposes a solution. In fact, there are feature requests aligned with this PR dating back to 2014, such as mesonbuild/meson#9. As far as I can see, the problem is not, as you conveniently suggest, that "nobody who works on Meson uses Windows" or " [it] is all volunteer work", but rather that there is someone who is able to stop things from moving forward if their only argument is "I don't like this". |
|
Please, continue to call me a liar.
If all you get out of that entire comment is "I don't like it," I have to assume you didn't actually read the comment. At the end of the day, I don't care whether you use Meson. No need to go on a monologue here in an unrelated PR, in an unrelated project. |
I don't see why this has specifically to do with Windows. That being said, ever since mesonbuild/meson@18b96cd you can use |
There is no portable way to pass a path to the vcpkg installation directory where the pkg-config binary is stored. Adding the pkg-config provided by vcpkg to the Cross files are not generally available in various third-party SDKs. This requires the user to manually fiddle with how things are installed. Note that some SDKs may be installed in trees that are not writable by the user, and may have version numbers in their paths. |
This adds the
compile_commands.jsonsetup for vscode-clangd.The main drawback here is that we are overwriting workspace configuration for clangd arguments. A solution for this is provided in clangd/vscode-clangd#544, but that PR has not received any attention so far.
Another problem is that clangd is not automatically restarted when its configuration is changed, so a manual restart is needed. It is solved in clangd/vscode-clangd#544 by creating a listener, but for now we need to workaround by manually issuing a
clangd.restartcommand. I believe we are racing with clangd init with this, as I've rarely seen some odd clangd warnings, but these didn't seem to be of major consequence.