Extension provides its own toolchain (gcc, gdb, etc.) but does not configure paths

[mark03]

I am using the latest (pre-release, version 3.something) official extension, on Linux.

Creating a new empty project went fairly smoothly (see my other form post about missing CMSIS headers), but when I tried to build the project, cmake couldn't find the toolchain.

It turns out that cmake was trying to run "arm-none-eabi-gcc" and so on, assuming that they would be in the current PATH!  In fact, these executables are bundled with the extension and (on my Linux system) are located in

~/.local/share/stm32cube/bundles/gnu-tools-for-stm32/13.3.1+st.8/bin

No one (at least on Linux---not sure what Windows users do these days) is going to want to modify their system path to add a weird bin directory just for a single application.  The right way to tell cmake where to find the tools is to either modify *its* environment or give it full paths to each tool.  But the extension did not do this when it was installed---I think that is a bug because it is easy to automate.

Complicating matters further, there are several places that cmake can be told where the tools are, but it turns out some of them get overridden and hence don't work.  For example, google's AI suggests to add CMAKE_C_COMPILER with the full path in CMakeLists, but that didn't work.  I finally figured out that I needed to create a .vscode/settings.json file with the stanza

 

"cmake.environment": {
"PATH": "/home/mark/.local/share/stm32cube/bundles/gnu-tools-for-stm32/13.3.1+st.8/bin:${env:PATH}"
},

(Interestingly, after I made the file, the extension added a bunch more stuff to it, but it didn't get created as part of the install.)

Again, it seems like this would be trivial for the extension to do automatically as part of the installation, since it knows exactly where the toolchain is located.

Thanks,

Mark

 

[Cartu38 OpenDev]

Hopefully on my side toolchain & co are set Thanks STM32 extensions.

Have you some metadata added to the project ? Sounds the way the stuff is supported.

If not having them ? maybe setup project is helpful ?

 

 

[mark03]

My bundles.store.json looks like this:

{
 "bundles": [
 {
 "name": "st-arm-clangd",
 "version": "^19.1.2+st.3"
 },
 {
 "name": "gnu-tools-for-stm32",
 "version": "^13.3.1+st.8"
 },
 {
 "name": "stlink-gdbserver",
 "version": "7.10.0+st.3"
 }
 ]
}

(I installed ninja using my OS package manager because the STM32 VSCode extension also couldn't find its own ninja installation.  There's probably a way to fix that too but I didn't pursue it because installing my own ninja was an easier solution.  I also have cmake already installed on my system.)

On my computer, "Setup STM32Cube project(s)" is shown but it is grayed out.  I'm not sure what that means.  I don't have STM32Cube stuff installed separately.  I only installed the STM32 VSCode extension and the system bundles shown above.  We're not supposed to install Cube outside of that process, are we?

In any case, I don't think any of this really relates to the reason I posted here.  You seem to be explaining ways to get things working.  I already have things working.  The point is that the path should be configured automatically, because the extension already knows exactly what the path is---it put the binaries there, after all.

[TDK]

The expected way to use VSCode for STM32 is to use STM32CubeMX to generate the project as a makefile project which you then open in VSCode.

https://community.st.com/t5/stm32-mcus/how-to-use-vs-code-with-stm32-microcontrollers/ta-p/742589

 

[mark03]

Much of that tutorial is out of date and incorrect for v3 of the extension.  For example, there is no STM32CubeCLT anymore (the extension brings its own toolchain as a "bundle").  And there is no longer any place in the extension settings to configure paths.

My impression is that the VSCode extension is trying to be self-sufficient.  Obviously you will run CubeMX for things like pin planning, and code generation if using HAL, but you are never prompted to run it when creating a blank project, at least in the latest prerelease (v3).

I guess it would help if there were updated documentation.  They are working on it, but it is very very sparse at the moment.

[vincent_grenet]

@mark03 your shared bundles.store.json looks promising but is not complete. You should get as extra from early begining cmake & ninja as part of.

Yes you're right CLT is gone with this fresh initiative and is self sufficient Thanks some new objects so called STM32Cube bundles allowing to serve the same but more smart, flexible way enabling partial update, continuous delivery more, more control to the end user.

Working this way, yes, path management is handled under to hood for you and you have as end user to take no care about. Already it's bare minimum service we want to serve plus ambition to promote unique flexibility to end user. Flexibility considering Thanks this fresh bundle system and under the hood mechanism, you will be able to get PATH like definition per project and not global to your VSCode instance or worse to your system. Bundle system is managing dynamically and under the hood PATH definition. To understand it a bit more (yes we are working on some documentation, apologize for delay) please have a try from a VSCode integrated terminal to run the following command from root directory of your project (location where .settings folder is):

cube --resolve stlink-gdbserver--pure

... you will see what magic is under the hood: looks at PATH variable you should get collection of bundle(s) contribution(s).

Having as expected cmake & ninja as part of your bundles.store.json you should be able to run the following commands:

cube cmake --version
cube ninja --version

.. getting as result proof these tools are set and starting to get you understand based on bundles.store.json (project based so) you could get version of tool(s) you want per project.
Based on your bundles.store.json the following should give some results the same:

cube stlink-gdbserver-pure --version

Please note, about cmake setup especially, you have to take care to not jeopardize tricks set to make it happens at the end. May sounds weird but forced to us enabling smooth integration keeping CMake Tools extension running what, we guess, all are appreciating.

Here are piece of explanation pending more accurate documentation.

Real issue is why are you not getting expected bundles.store.json file content ?
Could you have couple of trial forcing by hand ninja & cmake setups ? ... in order to see the system acting and helping us to support you acting as kind of local install sanity check.
1) Move to bundles manager view and select your project

2) Select ninja & cmake tools, elect versions and pust `Set` button

3) Look at your bundles.store.json file : cmake & nija has to be here !

 

 

 

 

[mark03]

Hi Vincent,

Thanks for the helpful walkthrough!  I went to the VSCode terminal like you said and was able to run those commands with no problem.  Then I double-checked the bundles manager and I see two entries (just like your picture), one for System and one for my project.  If I look at "System", cmake and ninja are both installed.  If I look at the bundles for my project, they are not installed.  Could this have something to do with using the "empty project" option?

I went ahead and selected the installed versions for cmake and ninja, then pressed Set, like you showed, for my *project* bundles list.  Then I deleted the build folder and ran cmake configuration.  Now everything works.  (I even got rid of the path statement in my .vscode/settings.json.)  So it looks like this was the problem all along---cmake and ninja bundles were installed but for some reason not selected in my project, and it was trying to find them in the system path.

I can mark your reply as a solution but I wonder if there is more to this...  I should really try a fresh installation without any other extensions and see if the same thing happens.  Unfortunately I don't have time to try that :\

 

[vincent_grenet]

@mark03, I am happy to receive a positive conclusion and appreciate you taking the time to update us all.

I confirm that it should have been set properly from the beginning when requesting an empty project, so something must have gone wrong. Unfortunately, I am not able to reproduce the issue on my side. If you have an opportunity to reproduce it or can point out the issue again, please feel free to let us know.

The "System" allows you to manage local installations on your computer. Then, each project can be set up by selecting from these local assets. Each project can then live its own life, which is part of our new proposal.
I hope you foresee some value here ... more to come.

[mark03]

If there is a bug, I'm sure it will pop up again before long ;)

One complicating factor in my environment is the fact that I was already using VSCode with the older, non-ST extensions for MCU development.  There could be some negative interaction there, but I didn't want to uninstall them quite yet.  I'm also using "Code OSS", the free-software-packaged version of VSCode.  And running on an unsupported Linux distribution (although I doubt that matters).

Appreciate the work you are doing here.  Thanks again!

[vincent_grenet]

When it comes to complex setups within VSCode, I may like https://code.visualstudio.com/docs/configure/profiles. It is not always usable depending on your way of working, but it helps a lot to isolate contributions.

Adding this fresh STM32Cube contribution to a dedicated profile may help. (VSCodium and others do not support profiles, though.)