This partially reverts 3c1eee5bed.
I thought that it is not necessary, but
https://mesonbuild.com/Reference-manual_functions.html#vcs_tag says:
> This method returns a custom_tgt should be used to signal dependencies if
> other targets use the file outputted by this.
>
> For example, if you generate a header with this and want to use that in a
> build target, you must add the return value to the sources of that build
> target. Without that, Meson will not know the order in which to build the
> targets.
We can use version_h directly, since we already have it.
Hopefully fixes https://github.com/systemd/systemd/issues/28994.
Let's also use vcs_tag() when we're doing a non-git build. In those scenarios,
the build would normally be done just once in a given copy, so doing an extra
call does not matter. We can save a few lines of meson config.
The special path was added in 064b8e2c99, with
the justifaction that vcs_tag() is slow and -Dversion-tag=foo can be used to
fix the version tag and speed up partial rebuilds. I think the justification
for this is weak: having an accurate version tag is particularly useful when
developing the code. Shaving of a fraction of a second at the cost of having to
manually update the version seems iffy.
Secondly, with vcs_tag() we can be pretty sure that meson will build the
version file first and that it'll be available to all build steps. Because we
didn't use version tag, we had to manually specify the dependency on version.h
in various places. It seems nicer to use vcs_tag() and not have to deal with
this problem at all.
Finally, the savings in time seem much smaller than back when
064b8e2c99 was made. It reported a change
from 94 ms to 521 ms. But now the difference seems to be about 50 ms:
Before this patch:
$ time ninja -C build
ninja: Entering directory `build'
ninja: no work to do.
ninja -C build 0.04s user 0.02s system 97% cpu 0.057 total
ninja -C build 0.03s user 0.01s system 97% cpu 0.049 total
ninja -C build 0.03s user 0.02s system 96% cpu 0.051 total
ninja -C build 0.03s user 0.01s system 96% cpu 0.049 total
ninja -C build 0.03s user 0.01s system 97% cpu 0.046 total
With the two patches in this PR:
systemd-stable [drop-versiondep] time ninja -C build
ninja: Entering directory `build'
[1/669] Generating version.h with a custom command
ninja -C build 0.08s user 0.03s system 98% cpu 0.106 total
ninja -C build 0.08s user 0.03s system 98% cpu 0.104 total
ninja -C build 0.09s user 0.02s system 98% cpu 0.116 total
ninja -C build 0.08s user 0.02s system 97% cpu 0.108 total
Overall, I think the tiny time savings are not worth the complexity.
The use of vcs_tag was dropped in #28567, which results in builds having
stale version information once new commit are made.
This also fixes a case where CI builds would have no version information
because they are checked out without any tags for git-describe to use.
Additionally, use `--git-dir` now, as that particular issues seems to
have been fixed by now.
We went back-and-forth a bit on this. Very old meson would print a message
about detecting the program if a quoted argument was used, leading to a lot of
noise. So we started to convert various places to use the variable, but then it
turned out that meson < 0.56.2 doesn't handle this correctly and we reverted to
using strings everywhere in 7c22f07cbd. Then at
some point we stopped supporting old meson and over time we started using the
variable in various places again, somewhat inconsistently. Then most calls to
'sh' were removed in 9289e093ae when
install_emptydir() builtin started being used.
Now meson allows either the string or variable to be used, and doesn't print a
message if the string is used. Let's use the variable everywhere. For 'sh', we
could do either, but for other variables, we _do_ want the detection to happen,
for example for git, find, awk, which might not be installed and we want to
detect that early, before we start the build. It would be ugly to use quotes
for some programs, but not for others. Also, a string is still refused for
test(), so we couldn't use the string version even if we didn't care about
detection.
Now that we use meson feature options for our dependencies, we can just
rely on '--auto-features=disabled' to do the same. One benefit of this
is that specific features can still be force-enabled by overriding it
with the appropriate '-Dfeature=enabled' flag.
The two remaining uses for skip-deps can simply rely on their default
logic that sets the value to 'no' when the dependency is disabled.
Also, there is no need to conditionalize the get_variable() calls
because not-found dependencies will just return the passed default value
if provided.
This uses a two-step approach to make sure we can fall back to
find_library(), while also skipping the detection if the features are
explicitly disabled.
By making this a disabler dependency, we can slightly simplify the code
and it als fixes the build for -Dfdisk=disabled as we failed to create a
fallback empty libshared_fdisk variable.
By using meson features we can replace the handcrafted dependency
auto-detection by just passing the value from get_option directly to the
required arg for dependency, find_library etc.
'auto' features make the dependency optional, 'enabled' requires it
while 'disabled' features will skip detection entirely.
Any skipped or not found dependency will just be a no-op when passed to
build steps and therefore we can also skip the creation of empty vars.
The use of skip_deps for these is dropped here as meson provides a way
to disable all optional features in one go by passing
'-Dauto_features=disabled'.
This is a magic string, and we should avoid stepping into the territory
of normal keymap names with that, given that users can pick names
otherwise freely.
Hence, prefix the name with a special char to avoid any namespace
issues.
Follow-up for: #28660
This partially revert 0454cf05d3.
The executable actually does not work with itself, but needs to be
combined with test-udev.py. But, even so, the executable is for testing.
In the next commit, test and normal executables are declared in the same
way, and naming of the executable becomes essential to classify them.
Let's rename the executable and prefix with 'test-'.
One of the notable change is that previously test-sysusers.sh was installed
unconditionally, but now it is installed only when sysusers is enabled.
Another change is that test-sysv-generator is now re-introduced which
was mistakenly dropped by 6c713961ab.
CentOS 8 ships python 3.6 so let's try and stay compatible with that
since the only feature we're using that requires python 3.9 is the
streamlined type annotations which are trivial to convert back to
the older stuff to stay compatible with python 3.6.
When running from the build directory systemd-detect-virt might not be installed,
so tell meson to set up the PATH accordingly to point to the build directory.
Fixes https://github.com/systemd/systemd/issues/28316
When building on a x32 system we need to explicitly pass `-m64` to get
the right ABI as the kernel and EFI are still 64bit. For this to
actually work, a suitable multilib compiler, 32bit libc headers and
libgcc need to be installed (similar to ia32 builds on x86_64).
On x32 efi_arch will be set as the kernel architecture is just x86_64,
but there's no userland support to build the EFI ABI. When -Dbootloader=false
is set, skip libefitest too.
Some distributions still use glibc's libcrypt. In that case, libcrypt.pc
does not exist and dependency() will fail.
Also, even if libxcrypt is used, there may not be a symlink
from libcrypt.pc to libxcrypt.pc. So, let's add a secondary name.
Follow-up for d625f717db.
Fixes#28289.
This also drops the fallback for libacl, libcap, libcrypt, and libgcrypt,
as recent Ubuntu (at least, 20.04 LTS and newer) and Debian (at least, buster
and newer) have relevant .pc files.
Fixes#28161.
This changes the generated config.h file thusly:
-#define _GNU_SOURCE
+#define _GNU_SOURCE 1
Canonically, _GNU_SOURCE is just defined, without any value, but g++ defines
_GNU_SOURCE implicitly [1]. This causes a warning about a redefinition during
complilation of C++ programs after '-include config.h'. Our config attempts to
inject this (and a bunch of other arguments) into all compliations. But before
meson 0.54, flags for dependencies were not propagated correctly (*), and the C++
compilation was done without various flags (**). Once that was fixed, we started
getting a warning.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined
(*) Actually, the changelog doesn't say anything. But it mentions various work
related to dependency propagation, and apparently this changes as a side
effect.
(**) -fno-strict-aliasing
-fstrict-flex-arrays=1
-fvisibility=hidden
-fno-omit-frame-pointer
-include config.h
This could be solved in various ways, but it'd require either making the
compilation command line longer, which we want to avoid for readability of the
build logs, or splitting the logic to define the args for C++ progs separately,
which would make our meson.build files more complicated. Changing the
definition to '1' also solves the issue (because apparently now we match the
implicit definition), and shouldn't have other effects. I checked compilation
with gcc and clang. Maybe on other systems this could cause problems. We can
revisit if people report issues.
