stm32cubeclt overriding system path variable

[Tizio1234]

I don't know if this is caused by the vscode extension or stm32cubeclt, but after the installation(everything related to the extension works), I noticed that the system path variable had been modified to add stm32cubeclt bin directories(I found this script: /etc/profile.d/cubeclt-bin-path_1.15.1.sh).
Is this normal? I want to use my system default cmake, is there a workaround instead of using /usr/bin/cmake every time?
I'm using debian 12.

[Nawres GHARBI]

hi @Tizio1234 

yes the install will add the bin of cubeCLT into the system path. 

If you want use your own, you can change the path but be sure the you are meeting the min version constraints of cmake

[Tizio1234]

The esp-idf framework doesn't edit system path, it has a .sh like stm32cubeclt, that gets executed only when necessary, is something like that doable with stm32cubeclt?

[Nawres GHARBI]

actually not but can check with the dev if feasable

[Tizio1234]

Thank you, this thing is pretty annoying

[mattias norlander · Accepted solution]

Hi @Tizio1234,

Solutions are in the pipe. Today we provide one "fat package" called STM32CubeCLT. Like you say CLT put tools on the system PATH. Not so nice.

Consider CubeCLT as a short-term solution providing a "turn-key solution" with VS Code. We don't consider CubeCLT flexible for customer nor scalable/maintainable for ST.

In the future we will split CubeCLT into smaller parts and use a package manager to allow customers to conveniently source all the required tools to enable build, debug and other use cases.
This idea should help users simplifying the download/update workflows.
As part of this we will provide mechanisms so that you at project-level can define which CMake version you want to use to build the project.

Does it sound like a solution for your problem?

A question for you: What are the main reasons as to why you want to use your system provided CMake version?

Very open to feedback! :)

[Tizio1234]

Thank you for your time and assistance, the package manager alternative sounds a lot better, it would definitely improve the experience with stm32 software development, it would be amazing to have a solution that makes embedded software development as easy as developing for host machines.

Regarding the CMake "problem", I just like things clean and separated from the rest, this way l can have multiple embedded SW platforms(esp-idf, zephyr, cube, as of now, this is just an example), each of those platform should only be able to use the right software, there are many ways to do that, I like to create an environment script for each SW platform I have on my host machine. In many IDEs/code editors there's some kind of option for an environment file, so the project stays separate from the IDE.
Not like stm32cubeide, or atollic truestudio some time ago, or the preferred ide by some company; this can be achieved by developing good sdks and using cmake or something like that.

[ecorm]

---

@mattias norlander wrote:

A question for you: What are the main reasons as to why you want to use your system provided CMake version?

---

Because we use our computers for projects other than STM32. Clobbering our system PATH like that so that it hides the OS-provided tools is bad form.

Please keep in mind that your customers have lives outside of the STM32 ecosystem (e.g. desktop development).

[ecorm]

---

@mattias norlander wrote:

Very open to feedback! :)

---

Instead of appending to the user's PATH so that if affects all their shell sessions, provide a script that starts an interactive subshell with the modified PATH. See the Visual Studio Developer Command Prompt for inspiration.

In your VS Code extension, make it explicitly use the configured CubeCLT path; do not rely on your tools being in the user's PATH.

[vincent_grenet]

@ecorm, please be aware that the new 3.x.y STM32CubeIDE extension pack for Visual Studio is moving away from using the CLT and promoting the use of STM32Cube bundles instead.

Not only are we leaving behind the single monolithic delivery (which the CLT represents), but we have also revised the way PATH is managed. When you use it, you will notice that we no longer update the system PATH but only the interactive subshell PATH.