How to prevent modifications of c_cpp_properties.json by the extension?

[bfxdev]

As a corollary of the request to automatically fill the c_cpp_properties.json file, as I would like to provide such a file as part of my GIT repositories,

I find it annoying that the file is automatically modified in recent versions of the extension. Then the file is marked for commit by GIT, and may be pushed by mistake to the online repository. Even worse, as absolute paths are added, the newly modified file shows the local name of the user, what may not be wished (if confidentiality is a necessary).

In addition, it is not very clear to me what the trigger is for modification and until now, according to my experience so far, most of the time the added path does not solve the squiggles in IntelliSense.

Is there a way to de-activate this automatic modification?

[ArthurMa1978]

If without the c_cpp_properties.json file the IntelliSense of C/C++ will totally not work, and most of our customers don't know how to fix this file, this why we provide this automation function.
How about add this file to gitignor?

[bfxdev]

Thanks for feedback and the work on this issue. Well, I understand the difficulty to build the json file, no question about that. That is why I want to provide a good, default-engine-capable json file with my sketches for anybody trying to follow or modify the code with VSCode, after cloning the git repository. So adding the file to .gitignore is no option, because the file would not be cloned. The change could take the form of a new VSCode global/project setting, like "Generate/modify c_cpp_properties.json file for Arduino" with different states: - "Always": current behavior - "For added libraries or if not present": at board selection, generate json file with board-specific paths only if there is no file already there. Add paths for added libraries in existing file (generate file if necessary). This should be the default setting. - "Do not touch if present": Generate a default file if not there, but never change it if there is one. This would be my own setting I think. This is really a first proposal. Wording or scope needs probably to be adapted to other needs or features I'm not aware of. Le lun. 15 juil. 2019 à 05:15, Arthur Ma <notifications@github.com> a écrit :

…

If without the c_cpp_properties.json file the IntelliSense of C/C++ will totally not work, and most of our customers don't know how to fix this file, this why we provide this automation function. How about add this file to gitignor? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#850?email_source=notifications&email_token=ACYNB2GVGCSZGBHNTBRBOFTP7PTV5A5CNFSM4H5YVDYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4UEWA#issuecomment-511263320>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACYNB2GTNVM5AMYQFOEDTTDP7PTV5ANCNFSM4H5YVDYA> .

[mMerlin]

I think you can do both. Add the c_cpp_properties.json to your git repository, AND specify it in the .gitignore file. It will be in the repository, and downloaded when the repository is cloned, but git will not offer to add any changes to it back to the repository on git add -A. Someone in the know can still make changes by explicitly adding the changed file to staging. Even if that means temporarily changing .gitignore. It think (not 100% sure) that changing .gitignore is not needed. git add .vscode/c_cpp_properties.json should add the file to staging, even if it is being ignored. And commit should grab everything in staging, without looking at ignore.

[escaner]

I agree with bfxdev: modifying the c_cpp_properties without asking every time I open vscode is quite annoying. For example, I have a path defined as "${HOME}/.arduino15/packages/SparkFun/hardware/avr/1.1.12/**" and the extension keeps adding the same path again, but with the $HOME expanded.

The only way I have found to stop this happening is removing the write permissions on the file, but of course, it is not that convenient as then I cannot modify it myself anymore.

[sslupsky]

It looks like this "feature" was added a while ago by this PR #795

The way the feature currently works is broken. The auto update adds two recursive paths, one to the core root and another to the tools root. Unfortunately, those two recursive paths have a tremendous number of conflicts which leads to countless time running down squiggles that are not indicative of problems. It renders Intellisense useless because intellisense doesn't seem to have any intelligence when it comes to selecting an include from any number of includes it finds when it recursively traverses a path. As a result, IntelliSense will almost always pick the wrong path and the wrong include.

Please remove the recursive directory paths provided by this feature and replace them with multiple non recursive paths. Please also give us the option to turn this feature off until at least this feature is working properly. The option to turn off a path could be granular enough to turn on or off specific paths the plugin thinks would be helpful.

[sslupsky]

I attempted to use the suggestion from @escaner and changed the permissions so the file cannot be written. Unfortunately, there is still some problem with this plugin. I have attached a screen shot of the directory paths is appears to be using:

Here is the path in the c_cpp_properties.json file:

"~/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/arm-none-eabi/include/"

As you can see, this path is not recursive. Moreover, it is 4 levels deeper than the tools root. The screen shot shows that intellisense picked up the include from three different paths and it chose the wrong one.

The the first case, the plugin appears to have traversed a sub directory three levels deeper:
"~/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/7-2017q4/arm-none-eabi/include/c++/7.2.1/tr1"

In the second case, this is the correct path according to the path I specified in the config file.

In the third case, the plugin appears to have traversed a path that begins two levels up from the path I specified. This should be impossible.

It appears the plugin ignores that fact that the two library paths were not present in the configuration file and uses them anyway.

[sslupsky]

@ArthurMa1978 This is quite clearly a major bug that should be fixed asap.

[elektronikworkshop]

Hi to everyone who is suffering from this!

I was so annoyed, that I began to work on an auto-configuration mechanism, which parses the build output from Arduino and creates a c_cpp_properties.json from it. The goal is that no one wants likely ever edit this file manually again - except for very weird setups for which I will add a configuration flag/option that will keep the extension from touching the file.

I coded some proof of concept already but I haven't committed anything yet. But I began documenting the project here.

Anyone who wants to keep me motivated can chip in some 🍺-money - the donation button can be found in the link above.

Other support is appreciated and comprises

• people with Windows and OSX setups to test the cross platform compatibility
• the original maintainers could help me with CI and how to build test-releases

The progress can be followed within the same file. The repo is set to this feature branch by default.