CMake

[switchabl]

Well, yes, I wouldn't disagree with that. I mostly figured it out in the end and managed to port some non-trivial examples to a custom board as well (including logging over RTT and serial). But it definitely wasn't fun and involved several hours of methodically working through the source files because the documentation was not exactly helpful.

BTW The basic SDK blinky actually needs just 4 source files (including main.c). But I think they ran into the same problem I had and they didn't have time to figure out all the dependencies manually for each example. So instead they decided to build the whole kitchensink every time and let the linker throw most of it away. Of course, as soon as you switch to something more complex with a wireless stack, you DO need a lot more files but that seems unavoidable.

[SiliconWizard]

Sure, but unfortunately, in the embedded world, more and more vendors are switching to CMake for their SDKs, so even for a small project using a modern MCU, you may be faced with CMake.

I have personally run into two such vendors for MCUs that I've used: RPi with the RP2040 and NXP with the iMXRT series. In both cases, the CMake file hierarchies were so intricate that it drove me nuts. In both cases, I wrote my own makefiles for using the SDKs. That took a bit of time (mostly due to figuring out where SDK files were and handling the hierarchy). You can of course do without the SDKs altogether. But while this is absolutely doable for something like the RP2040, good luck with something as complex as a iMXRT106x.

I had the opposite experience a while ago. The (legacy) nRF5 SDK comes with plain Makefiles. But it consists of many small modules that each depend on other modules. In the end I had to:
1. make
2. find each missing include and add path
3. for each linker error find source file that defines the symbol and add to sources
4. goto 1 until build succeeds

And that can take quite a few iterations, so I was really wishing they had used some kind of build system to handle the dependencies. And in fact it turned out someone else was so annoyed by this that they put together... a set of CMake files (https://github.com/Polidea/cmake-nRF5x).

Well, this is actually quite a similar point, but with a different tool. As soon as you want to build in a slightly different way than what the vendor provides - sometimes requiring the whole shebang just for building a trivial test program - it becomes an intractable mess. In the same vein, good luck with the ESP32 SDK as well. It's not badly done as long as you strictly follow the way they want you to use it, but any change in the way you want to build stuff is a major headache.

I hate this new trend (which is often seen with CMake, but admittedly not only) of those SDKs with very deep hierarchies down to sometimes 1 source file per directory, with even a separate subidrectory for include files. It sure makes compiling it in any different way than exactly what the vendor provides you as examples or automatically generated stuff, a major PITA.

But ultimately this is down to the dreaded software bloat that is now infecting embedded development as well.

To paraphrase a famous saying which goes like "war is much too serious a thing to be left to the military", I will just say that software is much too serious a thing to be left to software engineers.

[newbrain]

I, personally, like CMake.
At work, in one morning I was able to use it effectively, if not of course efficiently and smartly, after having struggled for days with the baroque mess that autotools is.
In the end I had to cave in (as in having someone else do it...) since autotools (plus bitbake plus yocto) is our standard toolchain.

The RP2040/pico SDK is a bit of a red herring, they overcomplicated it "a little bit" - though it sports some nice automation: when you add a library, the include path for the relevant .h is automatically added (had they avoided their maze of twisty little directories, all alike, this would not be a point...  CMake does not force you in that direction).

I use it for my my projects, if only because I really dislike Makefile syntax* and builds with ninja are insanely fast (and you can't write ninja by hand)
For the same project, about 200 kLOC, AMD 5900X: make 12 s, CMake+ninja - including build system regeneration - 2 s (I know, 1 sample is not data).

CMake integration in VS Code (and VS, too!) is extremely good and helpful, this is of course not a virtue of CMake, but still it helps and make for a good experience.

The language is not "pleasant", a bit COBOLesque in verbosity, but it's very flexible, multi platform - my builds are unchanged across Linux, Windows, macOS - and easy to create templates with.

I'm starting to study meson - I like what I've seen so far and might prefer it in the end, but I literally started a handful of hours ago.

*  it's slightly ironic to see a number of python "indentation is semantic" bashers sing the praise of makefiles...

[brucehoult]

*  it's slightly ironic to see a number of python "indentation is semantic" bashers sing the praise of makefiles...

There's only "indented" or "not indented" -- same as many assembly languages -- which doesn't really seem comparable to Python.

I don't like makefiles much. They're ok for simple tasks, but some people overdo it by far.

Makefiles do two very different tasks:

1) describe the structure of your project and sub-projects, the dependencies between things, and how to build things from their dependencies

2) a breadth-first traversal of the dependency graph, executing the actions

Traditional e.g. GNU make does the second one tolerably well, though ninja is better.

It does the first part really quite badly, once projects get complex. That's where cmake and others come in.

A basic makefile format with completely expanded and explicit dependencies and build actions is a reasonable interface between the first and second tasks. It doesn't matter these days if it is a few MB in size.

[DiTBho]

Makefiles do two very different tasks:

1) describe the structure of your project and sub-projects, the dependencies between things, and how to build things from their dependencies

2) a breadth-first traversal of the dependency graph, executing the actions

That's what my tools do for my-c.
I haven't yet completed the implementation of the second point you mentioned, threads + processes in parallel, in the right order.

Anyway the dependency engine is up and running.

[DiTBho]

Pascalish syntax, begin, end, why not? 

[SiliconWizard]

Pascalish syntax, begin, end, why not? 

Sure, why not. I personally have nothing against curly brackets to delimit blocks of whatever, though. Simple and effective.

[SiliconWizard]

Digressing a bit there, but I've heard a lot about ninja being so much faster than make. My few (and admittedly limited) tests so far have not shown much difference. I have for instance built KiCad with either ninja or make as a back-end. Build time was nearly identical. It's not a huge project, but it still takes a few minutes to build either way, so it's not small.

One very common misconception is to compare make and ninja using default options for both. This makes no sense: ninja is by default multi-threaded. Make is not. So obviously the time difference with default will be huge. But make can be multi-threaded using the "-j" option, and from again my limited testing, in this case both perform relatively similarly, with differences being marginal.

[DiTBho]

Yup multi threading
For my-c builder I also want clustering capability.
(modules compiled on different computers in parallel)
Distcc like, I mean
It will be next step

[brucehoult]

One very common misconception is to compare make and ninja using default options for both. This makes no sense: ninja is by default multi-threaded. Make is not. So obviously the time difference with default will be huge. But make can be multi-threaded using the "-j" option

You don't say :-)

My .profile has a line export MAKEOPTS="-j64" so I don't have to tyoe it every time.

I suppose I haven't deliberately run a single-threaded make (except maybe to debug something) since I got a dual 2.0 G5 Mac in 2002 or so, but it's completely pointless paying big bucks for a 32 core Threadripper and then using single-threaded make!

Ninja has some other very useful capabilities, such as being able to limit the number of parallel jobs of any one type, for example with the LLVM_PARALLEL_LINK_JOBS Cmake option when building LLVM (only available with ninja back end).

That lets you run 64 parallel gcc jobs, but limit parallel links (which use 10 or 12 GB RAM each) to 8 or 10 or whatever to avoid serious VM thrashing.

[SiliconWizard]

Ninja has some other very useful capabilities, such as being able to limit the number of parallel jobs of any one type, for example with the LLVM_PARALLEL_LINK_JOBS Cmake option when building LLVM (only available with ninja back end).

That lets you run 64 parallel gcc jobs, but limit parallel links (which use 10 or 12 GB RAM each) to 8 or 10 or whatever to avoid serious VM thrashing.

OK, I'll look into that. Sure make blindly parallelizes stuff when it can without any distinction. So that one could be useful.

[newbrain]

One very common misconception is to compare make and ninja using default options for both. This makes no sense: ninja is by default multi-threaded. Make is not. So obviously the time difference with default will be huge. But make can be multi-threaded using the "-j" option, and from again my limited testing, in this case both perform relatively similarly, with differences being marginal.

In my case at least, same -j option (24) for both. It might be something related to file access and how processes are spawned on Windows, but the difference was surprising. My friend reported a similar improvement on his Mac.
It has to be said that the Makefiles were the ones generated by that MCUxpresso turd, the CMakeLists.txt files were my doing.