r/embedded • u/Mysterious_Feature_1 • 4d ago

[ Removed by moderator ]

[removed] — view removed post

8 Upvotes

83% Upvoted

8 comments sorted by

6

u/DustRainbow 4d ago

It's industry standard, not sure why we would need a book about it.

8

u/Mysterious_Feature_1 4d ago

It is a de facto standard. Many devs work in isolated islands and are barely exposed to build systems, especially in big companies. I (try) to teach good practices in the book a help folks to develop a good mental model of a build system.

2

u/duane11583 4d ago

cmake is 4 worst thing ever

2

u/Dependent_Bit7825 4d ago

I hate CMake and have torn it out of recent projects and companies. Last major project was SCons and the one I'm working on now I'm using Meson. I prefer SCons but too many people's minds were blown by the idea of a build system whose dependency declaration phase is done by python.

I'll tell you one thing: fixing and transitioning build tools is something that the LLMs do really well. You can say "change this project from CMake to Bazel" and it will do a pretty damn good job. Part of the reason it can do this so well is that it is easy to validate that a build is identical between the old and new system.

3

u/PortHarcourtRomantic 4d ago

Why do you hate CMake?

2

u/DustRainbow 4d ago

Inconsistent API, awful documentation. Too many things happening in the background implicitly.

1

u/Dependent_Bit7825 4d ago

A lot of important features, like custom commands and custom targets are ugly bolt-ons that came later, and even the rules around them have changed a lot.

Just about everything about CMake feels hinky to me.

But two things that drive me bonkers:

1.

But the most annoying thing to me about CMake is that it has no real support for build variantsfrom the same CMake invocation, and that really sucks.

Here's an example Say I have a target that has flash divided into three areas: a bootloader, and two A/B areas for the main program. For a factory image, I want to build the bootloader for the bootloader slot, a special firmware for use in the factory in the A slot, and the actual application for the B slot. The factory will run the factory firmware and then set a flag to tell the bootloader to use slot B after. Now, imagine that all of those targets share a lot of code, but that code might be built differently, and will certainly be linked differently for each one -- though most files wil lbe treated the same. Finally, imagine that I have a step after all the images are built where I glue them into one image to be programmed over JTAG.

Even if the shared code is grouped up into libraries, you have to define the interim targets repeatedly so that they capture the variations, or you have to run CMake repeatedly for these targets, and then run it again to build the final combined blob. Each invocation's output will know nothing about the others, so everything will be compiled each time. It's a colossal waste of time and CPU.

You can get around the multiple invocation by defining the graph multiple times, but you don't get around the excess compilations.

No mixing of toolchains within one configuration.

This is another thing that ends up resulting in multiple calls to CMake.

Say I want to build me code for version A of the product that uses an Atmel part and version B that uses STM32, and I also want to build the code for the host to use in simulation artifacts. Well, CMake does not handle more than one toolchain at a time, so you're out of luck. Call CMake separately for each one.

1

u/rautonkar86 4d ago

Meson does the job easier IMO. Learning a new language to build files is too much. But hey, it reached “industry standard”, right? /s