git archive automatically uses gzip when --output=*.tar.gz is used, but
not for other extensions. Thus we need to invoke the compressor separately :(
It's a good pattern to use a variable for the repeating number, so let's
recommend that.
With meson-0.60, meson compile stopped working with some targets:
$ meson compile -C build update-man-rules
ERROR: Can't invoke target `update-man-rules`: ambiguous name. Add target type and/or path: `PATH/NAME:TYPE`
This is obviously a regression in meson, but based on a chat with the
maintainers, it seems that there's some disagreement as to whether 'meson
compile' is useful and how exactly it should work. Since we're already at
meson 0.60.3 and this hasn't been fixed, and people generally don't seem to
consider this an issue, let's return to documenting the usual practice of
'ninja -C build' that just works everywhere.
(Since nobody has raised any fuss in systemd, it means that people are
generally using the shorter form during development too. I only noticed
because I pasted a command from the release docs when preparing -rc1.)
After various long discussions
(https://lists.freedesktop.org/archives/systemd-devel/2022-March/047587.html,
https://lwn.net/Articles/889610/), there is no clear answer what the minimum
version should be. Bumping the version above 3.15 doesn't allow us to make any
significant simplifications (unless we went *much* higher). In particular, even
renameat2() is not fully supported with latest kernel versions, e.g. nfs still
doesn't have it. And the bpf stuff is optional anyway. So let's just say that
4.15 is what we recommend, because it provides fairly complete cgroups-v2, but
without any removals of compat in the code.
Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work
with timerfd in kernel 3.15 (i.e. back in 2014), let's require support
for it now.
This will raise our baseline only modestly from 3.13 → 3.15.
This version is from 2017 and should be stale enough to not cause
an outrage. All the relevant distros have it or a newer version.
We also already depend on some symbols defined in 3.0.5 anyway,
so let's take the opportunity to reduce our missing_efi.h
baggage.
Instead of embedding the commands to invoke directly in the macros,
let's use a helper script as indirection. This has a couple of advantages:
- the macro language is awkward, we need to suffix most commands by "|| :"
and "\", which is easy to get wrong. In the new scheme, the macro becomes
a single simple command.
- in the script we can use normal syntax highlighting, shellcheck, etc.
- it's also easier to test the invoked commands by invoking the helper
manually.
- most importantly, the logic is contained in the helper, i.e. we can
update systemd rpm and everything uses the new helper. Before, we would
have to rebuild all packages to update the macro definition.
This raises the question whether it makes sense to use the lua scriptlets when
the real work is done in a bash script. I think it's OK: we still have the
efficient lua scripts that do the short scripts, and we use a single shared
implementation in bash to do the more complex stuff.
The meson version is raised to 0.47 because that's needed for install_mode.
We were planning to raise the required version anyway…
m4 was hugely popular in the past, because autotools, automake, flex, bison and
many other things used it. But nowadays it much less popular, and might not even
be installed in the buildroot. (m4 is small, so it doesn't make a big difference.)
(FWIW, Fedora dropped make from the buildroot now,
https://fedoraproject.org/wiki/Changes/Remove_make_from_BuildRoot. I think it's
reasonable to assume that m4 will be dropped at some point too.)
The main reason to drop m4 is that the syntax is not very nice, and we should
minimize the number of different syntaxes that we use. We still have two
(configure_file() with @FOO@ and jinja2 templates with {{foo}} and the
pythonesque conditional expressions), but at least we don't need m4 (with
m4_dnl and `quotes').
