[systemd-devel] moving to the meson build system
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Thu Apr 6 01:56:03 UTC 2017
This is a proposal to move(*) to meson as the build system.
Initial, incomplete, implementation is at https://github.com/systemd/systemd/pull/5704.
Please have a look, see if it builds on your system, maybe send
a patch for some of the missing functionality.
Why? I'll just paste the text from the PR.
Reasons:
– simplicity: although the final number of lines is quite large (5k in
meson.builds vs 12k for Makefile.am + configure.ac + Makefile-man.am),
but it's all in a simple semi-declarative language. This was my first
contact with the language, and I got it working without too much
trouble. I hope meson will get even more high-level constructs in the
future, allowing us to simplify our rules.
— better error handling: if the command fails, the last command line
is printed along with stderr. Not intermixed with other output. Not
mangled. Ready to be copied and pasted and debugged. Syntax errors in
meson.build files are caught and reported (although the line numbers
are off).
— speed: full configuration and compilation from scratch:
$ time bash -c 'meson build && cd build && ninja-build'
...
bash -c 'meson build && cd build && ninja-build' 130.80s user 12.49s system 357% cpu 40.080 total
and partials builds are near-instantaneous:
$ touch ../src/login/logind.c && time nj
[2/2] Linking target systemd-logind
ninja-build 0.04s user 0.03s system 98% cpu 0.076 total
Michael Biebl provides some more detailed comparisons with autotools:
https://github.com/systemd/systemd/pull/5704#issuecomment-291875938
So far the meson build is not complete, but those results suggest that a full
build will be 5-12 times faster on a modern machine.
I'll be working on adding the missing pieces and fixing any bugs that
people encounter and once the patches are merged, I propose to release
systemd 234 with dual build systems, and drop autotools support a
few weeks later.
Zbyszek
(*) "move" and not "add another build system" because — realistically
— once the new stuff is working, assuming developers like it more,
the other build system will quickly atrophy.
More information about the systemd-devel
mailing list