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.