Open lefebvresam opened 4 months ago
do you have the setting "configurationProvider": "ms-vscode.cmake-tools" in c_cpp_properties.json? And also the cmake-tools extension installed of course. Then the include path are used that the compiler generates and Intellisense works much better than with other settings.
Do you mean this. Has no effect.
Yes, and do you have the CMake Extension installed?
that looks fine. I have also this setting in c_cpp_properties.json: "intelliSenseMode": "${default}",
In the build dir the file compile_commands.json is created and used by cmake, it contains many entries for 'thread'
I don't find one of these files in my test project. Where are they located and when are they created?
compile_commands.json is in my ./build/target folder and the export of this file the default setting in the cmake-extension. To get the subidr target created, check step 6 in: https://github.com/mbed-ce/mbed-os/wiki/Project-Setup:-VS-Code
The c_cpp_prorperties.json is located in the .vscode directory.
I have none of these files even after I generated the build folder again with the line you mentioned in settings.json:
strange, I have checked again, the compile_commands.json is created when I select the configuration in the CMake extension and the Mbed configuration has finished. Also the cmake.buildDirectory is not created as in the setting, it does not have the target name. So it looks like the extension is not running properly or is missing something.
But in my installation I see also this problem:
I had the same message on another pc yesterday, there I had no CMake Symbol in the left taskbar. After lot of trial, I got it working, but I couldn't find the exact reason.
I have the same message. What do you mean with ' select the configuration in the CMake extension and the Mbed configuration has finished'?
https://github.com/microsoft/vscode/issues/129466 looks more like a bug
I found this issue also, but it is old. Usually things get fixed soon, so in this case it may happen under some special circumstances.
When this CMake View is selected, you see the configuration. When the configuration is changed, it runs the cmake configure with the menu from cmake-variants.yaml.
So the configuration is not read, I see also no cmake-variants.yaml in your project root. Please check step 5 in the instructions.
I did the whole procedure and after run and debug nothing happens:
But I created a build shell script for it instead of using the baked in functionality for cmake. That's the reason that there were differences. I see now the red lines are away in the test project.
I was also wondering why compiling in home folder should be faster in case of WSL? My experiënce is that the best solution is to connect to a fast Linux build laptop next to you on the table. Then you unload your desk pc during compilation.
In Visual Studio Code there is a name resolver running in the background. But because of the fragmentation of the mbed code and the generation of some code parts during the build, the name resolver is not able to resolve everything. This can sometime be annoying if your are dealing with objects like Thread.
Then Thread is no longer underlined in red, but is pointing to the test classes, not the real ones. And they are different. If you point to the real one /rtos/inlcude/rtos/Thread.h the class is not found because of undifined macro's.
If you initialize and want tor recognize the os proirities:
I tested by printing out osPriorityBelowNormal and it is 16, so the real header used is: cmsis/CMSIS_5/CMSIS/RTOS2/Include/cmsis_os2.h
The test class is pointing to another (limited) version of cmsis_os2.h
This is very confusing and I don't know if it should be interesting to have a topic about SVC and name resolving, because it's an essential feature in programming. I don't know if it is technically possible to resolve to the right header names by VSC.