1671799bee
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 064b8e2c99ceb348c515353cc5c7d7bd05c49fcb, 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 064b8e2c99ceb348c515353cc5c7d7bd05c49fcb 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.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.