I ramble about my experiences with build systems for developing for embedded systems. I use radio, ARM, SoC’s (Nordic NRF5x family), but the discussion might apply more generally. I try to provide links, so you can explore.
Summary: I gradually migrated to CLI command line tools, using more recent tools instead of make.
History of what build systems I have used:
Those tools are in order of age, ease of use, and speed.
For example, make is:
- hard to use
while Meson is (?):
- easy to use
Factors to consider for a build system in this context
- supports cross compilation
- integrated with your IDE
- handles frequent changes to underlying SDK (Nordic’s)
- handles very many target embedded systems (platforms)
You might have many targets if you have a long-lived product that you will upgrade with new hardware:
- different vendors e.g. Nordic vs Silicon Labs)
- chip families NRF51x/52x
- versions within a family e.g. 52832, 52810, 52840
- devices and protocols that you use (i.e. Softdevice with Bluetooth, or other, or proprietary protocols.)
They get very large. They are not easy to understand or modify. But the ones Nordic provides are templates: you will need to modify them, and re modify them whenever you change the SDK.
Eclipse CDT managed build
Eclipse projects are distinguished by kind:
- “CDT managed build”: Eclipse generates makefiles.
- “Makefile managed build”: you provide and edit a makefile
CDT managed build uses a GUI. You must learn the structure of the GUI instead of the structure of a text configuration file (the makefile.)
Very few people seem to use it in the niche of embedded radios.
Nordic provides a tutorial for using Eclipse IDE for development, but the examples don’t use Eclipse “CDT managed build”, just “makefile managed build.” Again, that means you must edit the makefiles.
CMake and the Nordic SDK
Several people have implemented and published their own CMake scripts (macros) specific to the Nordic SDK:
Apparently Nordic realizes the benefit of newer build systems. Nordic CMake macros: IMO they are not very modular or extendable.
I found that my own scripts are fragile wrt SDK version.
There are a plethora of options for integration with the IDE:
The fact that there is a plethora is discouraging. It requires much reading to decide which to choose. It tells me there is no settled easiest way.
I disliked the projects generated by CMake. They were too different from my usual way of structuring a project.
Often I just used Eclipse as an editor, debugger, and version control wrapper, and built using the command line.
(I haven’t used Meson yet, I am still exploring it.)
One comparison of CMake and Meson.
Apparently Meson supports cross compiling: their documentation.
Meson is written in Python. That is encouraging, that they used a high-level, modern language to implement what is a very complex task. I would guess that one might even be able to understand any exceptions in the Meson implementation.
Apparently integration with IDE is in the future.
There is a Eclipse plugin editor for meson files.
The big picture
You need a mental model of the build process. You acquire that mental model after long experience. Learning and discarding build systems can help you form that mental model. The newer build systems more clearly represent the model. For example, using make you must remember what a “dependency” line looks like (foo: bar) while in newer build systems, a dependency might be labeled with text that says “dependency.”