Let's make sure that versions generated by meson-vcs-tag.sh always
sort higher than official and stable releases. We achieve this by
immediately updating the meson version in meson.build after a new
release. To make sure this version always sorts lower than future
rcs, we suffix it with "~devel" which will sort lower than "~rcX".
The new release workflow is to update the version in meson.build
for each rc and the official release and to also update the version
number after a new release to the next development version.
The full version is exposed as PROJECT_VERSION_FULL and used where
it makes sense over PROJECT_VERSION.
We also switch to reading the version from a meson.version file in
the repo instead of hardcoding it in meson.build. This makes it
easier to access both inside and outside of the project.
The meson-vcs-tag.sh script is rewritten to query the version from
meson.version instead of passing it in via the command line. This
makes it easier to use outside of systemd since users don't have to
query the version themselves first.
Follow-up for 4453ebe4db.
With the feature list all dandified, the most important part of the
output, i.e. the project name and version, are less visible.
version.h can be generated after compilation starts, creating a race condition
between compilation of various .c files and creation of version.h. Let's add it
as a dependency to more build targets that require version.h or build.h.
So far we played whack'a'mole by adding versiondep whenever compilation failed.
In principle any target which includes compilation (i.e. any that has .c
sources directly), could require this. I don't understand why we didn't see
more failures… But it seems reasonable to just add the dependency more widely.
This allows resolved and importd to be built without libgcrypt.
Note that we now say either 'cryptographic library' or 'cryptolib'.
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
The BLKID and ELFUTILS strings were present twice. Let's reaarange things so that
each times requires definition in exactly one place.
Also let's sort things a bit:
the "heavy hitters" like PAM/MAC first,
then crypto libs,
then other libs, alphabetically,
compressors,
and external compat integrations.
I think it's useful for users to group similar concepts together to some extent.
For example, when checking what compression is available, it helps a lot to have
them listed together.
FDISK is renamed to LIBFDISK to make it clear that this is about he library and
the executable.