workspace's settings.json options are overwritten

[ckkz-it]

I use code-server and have a predefined settings.json for the workspace. I set "C_Cpp_Runner.debuggerPath": "lldb" but it gets overwritten with defaults once I start the code-server. Is it possible to persist the initial value and provide defaults only for options that were not defined?

One note is that since it's the first time code-server is started, lldb binaries are fetched in the runtime (that's how CodeLLDB extension works) and are probably not there yet when your extension is initialized. The setting does persist if I change it manually after the initial start.

I run it in the devcontainer linux 6.10.0-linuxkit arm64. The extension is from the pack https://open-vsx.org/extension/franneck94/vscode-c-cpp-dev-extension-pack (the pack version is 0.10.0, and the extension version itself is 9.4.7).

[ckkz-it]

OK, I've checked the code and found that you already support it but require all three mandatory parameters to be set (cCompilerPath, cppCompilerPath, debuggerPath).

I see that you additionally validate if it exists using fs.accessSync but the issue with it is it doesn't work with binaries on the path, like gcc or g++, you have to specify the full path in the settings (i.e. /usr/local/bin/gcc).

Also, with lldb it's slightly different because as mentioned in the original comment it's fetched dynamically by the extension so it doesn't exist by the time you initialize settings (at least in my setup). To workaround this I had to do touch /usr/local/bin/lldb so the fs.accessSync check passes.

In the end, I have a working solution with this setup:

{
  "C_Cpp_Runner.cCompilerPath": "/usr/local/bin/gcc",
  "C_Cpp_Runner.cppCompilerPath": "/usr/local/bin/g++",
  "C_Cpp_Runner.debuggerPath": "/usr/local/bin/lldb"
}

I would like to contribute but want to hear your input first.

[franneck94]

The settings can also just have the commands name instead of a full path. So "GCC" should also work. Currently, I am not at a PC but somewhere I check if a command is found in the path

[ckkz-it]

So "GCC" should also work.

I've tested and it didn't work. Since fs.accessSync failed the extension assumed that I do not have such a file and used default values. Example, if you have this:

{
  "C_Cpp_Runner.cCompilerPath": "gcc",
  "C_Cpp_Runner.cppCompilerPath": "/usr/local/bin/g++",
  "C_Cpp_Runner.debuggerPath": "/usr/local/bin/lldb"
}

it will be turned into

{
  "C_Cpp_Runner.cCompilerPath": "gcc",
  "C_Cpp_Runner.cppCompilerPath": "g++",
  "C_Cpp_Runner.debuggerPath": "gdb"
}

[franneck94]

So "GCC" should also work.

I've tested and it didn't work. Since fs.accessSync failed the extension assumed that I do not have such a file and used default values. Example, if you have this:

{
  "C_Cpp_Runner.cCompilerPath": "gcc",
  "C_Cpp_Runner.cppCompilerPath": "/usr/local/bin/g++",
  "C_Cpp_Runner.debuggerPath": "/usr/local/bin/lldb"
}

it will be turned into

{
  "C_Cpp_Runner.cCompilerPath": "gcc",
  "C_Cpp_Runner.cppCompilerPath": "g++",
  "C_Cpp_Runner.debuggerPath": "gdb"
}

Dont you mean the lower is transformed in to the upper?

[franneck94]

Thats what i mean. I only check if the path exits, if its an absolute path

[ckkz-it]

I believe it won't even get to these lines of code. Here's the check that will fail with just gcc or g++ (it doesn't do any isNonRelativePath checks). It will result in a settingsMissing to be true which will force to overwrite local (workspace) settings by global ones (or default ones if there are no global). That's what I experienced when was testing.

[ckkz-it]

Dont you mean the lower is transformed in to the upper?

No, the upper is transformed into the lower. I don't have any global settings, just workspace settings.

[ckkz-it]

Here's what it looks like.

I'm changing it in my workspace .vscode/settings.json file:

then I start a code-server instance and open this settings file:

the settings got overwritten by the extension.

If I change gcc to /usr/local/bin/gcc in my initial settings and restart the server - it will work (since fs.accessSync will also now return true for the full gcc path).

[franneck94]

So if localSettingExist will also check for the program on PATH in addition to checking if its an abs path, it would work for you?

I am not sure why i added the pathExists check in the first place

[ckkz-it]

Yeah, that would be perfect. Check if it's accessible via the terminal since that's how it will be accessed later.