Meson Build System for Embedded Products - Reproducible Build System

[hgn]

Submission type

• Bug report

systemd version the issue has been seen with

Current and future versions

Used distribution

Yocto Linux and Custom Linux Distribution for Embedded/... Products

Bug report:

For embedded and custom Linux distributions a cross compile toolchain is used to build a target specific distribution. Especially if you build small, realtime specific products with a small footprint you compile a few userspace applications, started nowadays by systemd - fine. Nearly all C/C++ applications are build with autohell/make or cmake - which is fine because it is limited to two tools.

Switching SystemDs build system to meson requires the following: -> cross-compile python to build the system. There is no Python on Embedded Systems!

Even worse: the Python thing is probably doable, but meson and ninja is required too! This means that these dependencies must be fetched too (and probably other dependencies too). By using a complete different distribution mechanism: PIP. Think about fixing bugs for a 10 year old product, it requires that all target and build tools are somehow archived, this is not easy for tar.gz packaged products, but doable. Now think about pip modules, where you automatically do pip install <package>. Where comes this package from? Is this package in 10 years still available? This adds a huge burden for all embedded companies using SystemD.

Leave autohell/make as the build system!

[falconindy]

Two tools? Surely that's oversimplifying the situation. Using autotools means:

• autoconf (requiring awk and m4)
• automake (requiring perl)
• libtool
• initltool (more perl)
• make (requiring guile)

If, as you say, python is doable, then meson and ninja are trivial. ninja depends on libstdc++ and meson only depends on python.

[hgn]

I know, I simplified the environment to focus on the important aspects:

• before/now we had/have an dependency chain nearly all C/C++ applications using it (your bullet points)
• future: we still have these tools and we will have Python plus meson/ninja via a complete different distribution way: pip

IMHO systemd as the most fundamental application in a distribution should consider such aspects too. The world is not limited to Fedora/Server/Desktop where pip install is just a few keystrokes away. Reliable archiving the complete build toolchain for 15+ years is important too. The decision if using autohell/make vs. meson should consider such aspects too. Thank you @falconindy

[mbiebl]

You don't need pip to distribute meson. Just provide it in your archive like any other tool.

I understand that this means additonal work for you and meson is certainly still young and fast moving. But the benefits are just too great.
Especially for embedded systems, where building systemd can be quite slow, you might be interested to know that it can considerably speed up your build times.

The latest Debian version (234-1) uses meson. It cut the build times in half and less. This is quite impressive.
See https://buildd.debian.org/status/package.php?p=systemd and in particular a slower arch like e.g. mips: https://buildd.debian.org/status/logs.php?pkg=systemd&arch=mips

[fsateler]

Switching SystemDs build system to meson requires the following: -> cross-compile python to build the system. There is no Python on Embedded Systems!

If you are cross-compiling, why not cross-compile systemd too, and use the host python/meson/ninja?

[keszybz]

… and you also need to consider how much work it would be to required to maintain a second build system. Our configuration has lots of options, lots of autodetected features, and is quite complex. The autotools-based system is more complex, so keeping this second build system would more than double the effort spent on maintaining the build configuration. (More like triple it, because people tend to use and test just one of the two, so it's quite likely that when they write the patch for the other one, they get it wrong.)

I understand that this increases your workload. Nevertheless, meson seems genuinely better — so far we haven't discovered any significant regressions compared to autotools, and it's faster and more convenient and has much easier syntax, so it's a win for us. With time, meson will become more popular and there'll be other things which require it, and then it won't really matter if any single of those things provides an alternative build system, since you'll have to provide meson anyway. Sorry, but the gain from the switch is just too large for us, and the cost of keeping the old system around too high.

(Regarding distribution of meson: to expand on what @mbiebl said, it's also totally OK to just run it from its git repo. So there's certainly no need to install it using pip from the network.)

[poettering]

Also, do note that systemd with the switch to meson is not an outlier. In the broader ecosystem there's a general move towards meson visible, and sooner or later you have to deal with it anyway...

[hgn]

Thank you everyone! Still not great but we will have to cope with this ...

[boucman]

@hgn out of curiosity, what embedded build system are you using ?

[gunnarx]

... out of curiosity, what embedded build system are you using ?

@boucman - Yocto was mentioned in the first post. (I ended up here because I was searching for information on meson support in Yocto)