Skip to main content
Graduate
May 19, 2024
Solved

stm32cubeclt overriding system path variable

  • May 19, 2024
  • 2 replies
  • 3558 views

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.

    This topic has been closed for replies.
    Best answer by mattias norlander

    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! :)

    2 replies

    Technical Moderator
    May 20, 2024

    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

    Tizio1234Author
    Graduate
    May 26, 2024

    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?

    Technical Moderator
    June 6, 2024

    actually not but can check with the dev if feasable

    ST Employee
    October 21, 2025

    Hi @Tizio1234 and @ecorm ,

     

    No doubt developers are doing more than only STM32 development. Many companies are multi-sourcing MCUs within the same project for multiple reasons. Or developing C/C++ applications to be running on the host PC.

    Regardless our STM32 tool ecosystem cannot collide with whatever you want to do. When distributing our new CLI tools one challenge is to ensure that some contradicting requirements are fulfilled:

    • As mentioned below CubeCLT will disappear, but we still have the same need to distribute multiple small CLI tools like CMake, Ninja, GCC, LLVM, GDB, clangd, .... We cannot pollute your env-var with all of this.
    • And we also need to be able to ensure that "ST" delivered CLI tools are called by default (to guarantee a good out-of-the-box experience) when you are doing STM32 development, implying that we must be able to set env-vars for our tools...

     

    The new approach: Instead of polluting your environmental variables on your system, the new solution instead brings a "cube-wrapper" offering a managed cube CLI toolbox. You can run commands from inside an STM32 project context and ensure the right CLI tools of the right versions are called... As example:

    • Running the command "cube cmake" calls our bundles CMake version and also the right version of GCC or Clang/LLVM that the project has been frozen to use...
    • Running the command "cube programmer" will help you call the right version of CubeProgrammer to help you flash/reset target or any type of script automation you want to achieve.

    We are not 100% there yet, but this is the direction we are selecting to encompass your need to have a good out-of-the-box experience, guarantee re-producibility, while not tainting your system, nor colliding with other tools you have on your PC.