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.
