Discussion on: CMake on STM32 | Episode 1: the beginning

[Pierre Gradot]

Thanks!

The reason is because this serie is dedicated to CMake on MCU and I try to be as agnostic as possible from other tools than CMake itself.

The purpose is for people to understand how to write the CMakeLists.txt. Asking a tool to generate it is not exactly the best approach in my opinion.

Furthermore, CLion is not a free software (even if EAP might be a possible workaround). Even if I talked about it in my second episode, I didn't want it to a central piece of my articles.

Also, I talked about STM32 because I had to choose one MCU to write code examples. Using a tool that is dedicated to these families seemed to be even less agnostic.

To be honest, I haven't tried the STM32CubeMX support since it has been integrated directly in CLion. We used the 3rd party plugin, a long time ago. But I remember we didn't used the generated CMakeLists.txt for our project.

[Ilia Motornyi]

Ok, thanks, I fully understand your reasons.
In fact that generated CMakeLists.txt is quite close to your one, the same ideas behind. And it's possible that "3rd party plugin" was my old hobby project :-).

Some small notes about CMakeLists.txt:

• Toolchain file looks a bit overcomplicated thingy, I prefer(ed) to keep toolchain information in the same CMakeLists.txt(important note: above project clause). On the other hand, nowadays we have CMake presets feature, which may make the toolchain file a bit more user-friendly

• You do not need to use arm-none-eabi-size utility, the linker can print the same information, CMake clause add_link_options(-Wl,--print-memory-usage) does the trick

• If, at some point, you want to make a project with dual-core STM32H7xx, I have a template for CMakeLists.txt for this case, not tied to CLion, but extracting project information directly from STM32CubeMX files.

• I like your 3rd episode, that's a great idea to hide all of false-positive compiler warnings coming from libraries, that helps to keep actual project code error-free.

• I also like your C++ episodes, embedded software have to move towards stricter and safer languages.

[Pierre Gradot]

I guess it was! Thanks a lot for this plugin, it was the key to move from Eclipse to CLion. And moving to CMake & CLion was one of the greatest choices we made on this project!

About these small notes :)

• Using a tool chain seems to be the CMake way to cross-compile, that's why I show it here. If your project is solely made to generate a firmware for a MCU, then setting the toolchain directly in the CMakeLists.txt seems indeed simpler and as efficient. But once you want to also generate a PC-based software, for instance for unit tests and simulators, the toolchain file seems the obvious way. I wanted to make an episode about PC-executed unit tests but never took the time (for the moment?). I wasn't aware of CMake presets, I am going to check them! Thanks!

• You have missed the PS in my article ;) I wasn't aware of this option when I wrote the article. Must simpler indeed! And in the end it's bad for this article: it shows how to call an external software as a post-build step.

• Thanks for sharing. I hope I will use such a MCU one day.

• Thanks!

• Nice to see other people willing for the embedded world to move to C++. I have been using only C++ for the last 5 years. I will never go back to raw C. I have been looking for the Rust a little, but didn't try to run it on MCU for the moment. Maybe one day XD

[Ilia Motornyi]

Rust

Feel free to use my prototype for that. It worked 2 yrs ago:)

I wanted to make an episode about PC-executed

And I am now thinking about an article about emulator-running unit tests. A prototype works. One day.... You know :)

[Pierre Gradot]

I will have a look at it, thank you :)

Yes, I know...

I have tried out CMake presets and they are amazing. I still have a problem to load MVSC presets in CLion. I have a configure preset like this one:

     {
            "name": "mvsc",
            "inherits": "base",
            "description": "Base config for simulator with MSVC",
            "hidden": true,
            "generator": "CodeBlocks - NMake Makefiles"
        },

From the command-line, I must call vcvarsall.bat to configure the compiler before calling cmake --preset=a-preset-that-inherits-from-this-one.

In CLion, do you know how I can call this script when I use the action "Load CMake presets"?

[Ilia Motornyi]

The answer from my colleague:

You actually don't need to run vcvarsall.bat manually. CLion will take care of it. You need to:
configure Visual Studio toolchain in CLion
specify this toolchain in your preset using this JSON fragment:

"vendor": {
    "jetbrains.com/clion": {
      "toolchain": "<toolchain-name>"
    }
}

Here's a more detailed instruction: jetbrains.com/help/clion/cmake-pre...

[Pierre Gradot]

That's even better than asking the support directly! Thanks 😁

It does work if I add the key to the derived preset, but it does work on the base preset. It seems that the "vendor" map is not inherited.

When I read the documentation, it looks like a bug to me:

vendor

An optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. However, it should follow the same conventions as the root-level vendor field. If vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate.

[Ilia Motornyi]

Yeah, you are right. Now there is a ticket about it
youtrack.jetbrains.com/issue/CPP-2...

[Pierre Gradot]

That's perfect :)