Systemd/units/meson.build

350 lines
16 KiB
Meson
Raw Normal View History

# SPDX-License-Identifier: LGPL-2.1-or-later
with_runlevels = conf.get('HAVE_SYSV_COMPAT') == 1
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
units = [
['basic.target', ''],
['blockdev@.target', ''],
['bluetooth.target', ''],
['boot-complete.target', ''],
['cryptsetup-pre.target', 'HAVE_LIBCRYPTSETUP'],
['cryptsetup.target', 'HAVE_LIBCRYPTSETUP',
'sysinit.target.wants/'],
['dev-hugepages.mount', '',
'sysinit.target.wants/'],
['dev-mqueue.mount', '',
'sysinit.target.wants/'],
['emergency.target', ''],
['exit.target', ''],
['final.target', ''],
['first-boot-complete.target', ''],
['getty.target', '',
'multi-user.target.wants/'],
['getty-pre.target', ''],
['graphical.target', '',
'default.target' + (with_runlevels ? ' runlevel5.target' : '')],
['halt.target', ''],
['hibernate.target', 'ENABLE_HIBERNATE'],
['hybrid-sleep.target', 'ENABLE_HIBERNATE'],
2019-04-01 13:57:07 +02:00
['suspend-then-hibernate.target', 'ENABLE_HIBERNATE'],
2020-04-08 23:59:13 +02:00
['initrd-cleanup.service', 'ENABLE_INITRD'],
['initrd-fs.target', 'ENABLE_INITRD'],
['initrd-parse-etc.service', 'ENABLE_INITRD'],
['initrd-root-device.target', 'ENABLE_INITRD'],
['initrd-root-fs.target', 'ENABLE_INITRD'],
['initrd-switch-root.service', 'ENABLE_INITRD'],
['initrd-switch-root.target', 'ENABLE_INITRD'],
['initrd-udevadm-cleanup-db.service', 'ENABLE_INITRD'],
['initrd.target', 'ENABLE_INITRD'],
['kexec.target', ''],
['ldconfig.service', 'ENABLE_LDCONFIG',
'sysinit.target.wants/'],
['local-fs-pre.target', ''],
['local-fs.target', ''],
['machine.slice', 'ENABLE_MACHINED'],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['machines.target', 'ENABLE_MACHINED'],
['modprobe@.service', ''],
['multi-user.target', '',
(with_runlevels ? 'runlevel2.target runlevel3.target runlevel4.target' : '')],
['network-online.target', ''],
['network-pre.target', ''],
['network.target', ''],
['nss-lookup.target', ''],
['nss-user-lookup.target', ''],
['paths.target', ''],
['poweroff.target', '',
(with_runlevels ? 'runlevel0.target' : '')],
['printer.target', ''],
['proc-sys-fs-binfmt_misc.automount', 'ENABLE_BINFMT',
'sysinit.target.wants/'],
['proc-sys-fs-binfmt_misc.mount', 'ENABLE_BINFMT'],
['reboot.target', '',
'ctrl-alt-del.target' + (with_runlevels ? ' runlevel6.target' : '')],
['remote-cryptsetup.target', 'HAVE_LIBCRYPTSETUP',
'initrd-root-device.target.wants/'],
['remote-fs-pre.target', ''],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['remote-fs.target', ''],
['rescue.target', '',
(with_runlevels ? 'runlevel1.target' : '')],
['rpcbind.target', ''],
['shutdown.target', ''],
['sigpwr.target', ''],
['sleep.target', ''],
['slices.target', ''],
['smartcard.target', ''],
['sockets.target', ''],
['sound.target', ''],
['suspend.target', ''],
['swap.target', ''],
['sys-fs-fuse-connections.mount', '',
'sysinit.target.wants/'],
['sys-kernel-config.mount', '',
'sysinit.target.wants/'],
['sys-kernel-debug.mount', '',
'sysinit.target.wants/'],
['sys-kernel-tracing.mount', '',
'sysinit.target.wants/'],
['sysinit.target', ''],
['syslog.socket', ''],
['system-systemd\\x2dcryptsetup.slice', 'HAVE_LIBCRYPTSETUP'],
['system-update.target', ''],
['system-update-pre.target', ''],
['system-update-cleanup.service', ''],
['systemd-ask-password-console.path', '',
'sysinit.target.wants/'],
['systemd-ask-password-console.service', ''],
['systemd-ask-password-wall.path', '',
'multi-user.target.wants/'],
['systemd-ask-password-wall.service', ''],
['systemd-boot-system-token.service', 'ENABLE_EFI',
'sysinit.target.wants/'],
['systemd-coredump.socket', 'ENABLE_COREDUMP',
'sockets.target.wants/'],
['systemd-exit.service', ''],
['systemd-firstboot.service', 'ENABLE_FIRSTBOOT',
'sysinit.target.wants/'],
['systemd-halt.service', ''],
['systemd-homed-activate.service', 'ENABLE_HOMED'],
['systemd-initctl.socket', 'HAVE_SYSV_COMPAT',
'sockets.target.wants/'],
['systemd-journal-catalog-update.service', '',
'sysinit.target.wants/'],
['systemd-journal-flush.service', '',
'sysinit.target.wants/'],
['systemd-journal-gatewayd.socket', 'ENABLE_REMOTE HAVE_MICROHTTPD'],
['systemd-journal-remote.socket', 'ENABLE_REMOTE HAVE_MICROHTTPD'],
['systemd-journald-audit.socket', '',
'sockets.target.wants/'],
['systemd-journald-dev-log.socket', '',
'sockets.target.wants/'],
['systemd-journald.socket', '',
'sockets.target.wants/'],
['systemd-kexec.service', ''],
['systemd-machine-id-commit.service', '',
'sysinit.target.wants/'],
['systemd-journald@.socket', ''],
['systemd-journald-varlink@.socket', ''],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['systemd-networkd.socket', 'ENABLE_NETWORKD'],
['systemd-poweroff.service', ''],
['systemd-reboot.service', ''],
['systemd-rfkill.socket', 'ENABLE_RFKILL'],
['systemd-sysusers.service', 'ENABLE_SYSUSERS',
'sysinit.target.wants/'],
['systemd-tmpfiles-clean.service', 'ENABLE_TMPFILES'],
['systemd-tmpfiles-clean.timer', 'ENABLE_TMPFILES',
'timers.target.wants/'],
['systemd-tmpfiles-setup-dev.service', 'ENABLE_TMPFILES',
'sysinit.target.wants/'],
['systemd-tmpfiles-setup.service', 'ENABLE_TMPFILES',
'sysinit.target.wants/'],
['systemd-udevd-control.socket', '',
'sockets.target.wants/'],
['systemd-udev-settle.service', ''],
['systemd-udev-trigger.service', '',
'sysinit.target.wants/'],
['systemd-udevd-kernel.socket', '',
'sockets.target.wants/'],
['systemd-userdbd.socket', 'ENABLE_USERDB'],
['time-set.target', ''],
['time-sync.target', ''],
['timers.target', ''],
['tmp.mount', '',
'local-fs.target.wants/'],
['umount.target', ''],
2020-08-28 15:36:35 +02:00
['usb-gadget.target', ''],
['user.slice', ''],
['var-lib-machines.mount', 'ENABLE_MACHINED',
'remote-fs.target.wants/ machines.target.wants/'],
]
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
in_units = [
['debug-shell.service', ''],
['emergency.service', ''],
['kmod-static-nodes.service', 'HAVE_KMOD ENABLE_TMPFILES',
'sysinit.target.wants/'],
['quotaon.service', 'ENABLE_QUOTACHECK'],
['rc-local.service', 'HAVE_SYSV_COMPAT'],
['rescue.service', ''],
['systemd-backlight@.service', 'ENABLE_BACKLIGHT'],
['systemd-binfmt.service', 'ENABLE_BINFMT',
'sysinit.target.wants/'],
['systemd-bless-boot.service', 'ENABLE_EFI HAVE_BLKID'],
['systemd-boot-check-no-failures.service', ''],
['systemd-coredump@.service', 'ENABLE_COREDUMP'],
pstore: Tool to archive contents of pstore This patch introduces the systemd pstore service which will archive the contents of the Linux persistent storage filesystem, pstore, to other storage, thus preserving the existing information contained in the pstore, and clearing pstore storage for future error events. Linux provides a persistent storage file system, pstore[1], that can store error records when the kernel dies (or reboots or powers-off). These records in turn can be referenced to debug kernel problems (currently the kernel stuffs the tail of the dmesg, which also contains a stack backtrace, into pstore). The pstore file system supports a variety of backends that map onto persistent storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI variables[3 Appendix N Common Platform Error Record]. The pstore backends typically offer a relatively small amount of persistent storage, e.g. 64KiB, which can quickly fill up and thus prevent subsequent kernel crashes from recording errors. Thus there is a need to monitor and extract the pstore contents so that future kernel problems can also record information in the pstore. The pstore service is independent of the kdump service. In cloud environments specifically, host and guest filesystems are on remote filesystems (eg. iSCSI or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation of networking software *and* hardware *and* infrastructure. Thus it may not be possible to capture a kernel coredump to a file since writes over the network may not be possible. The pstore backend, on the other hand, is completely local and provides a path to store error records which will survive a reboot and aid in post-mortem debugging. Usage Notes: This tool moves files from /sys/fs/pstore into /var/lib/systemd/pstore. To enable kernel recording of error records into pstore, one must either pass crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y > /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option invokes the recording of errors into pstore *before* an attempt to kexec/kdump on a kernel crash. Optionally, to record reboots and shutdowns in the pstore, one can either pass the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y > /sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the shutdown path to record information via pstore. This pstore service is a oneshot service. When run, the service invokes systemd-pstore which is a tool that performs the following: - reads the pstore.conf configuration file - collects the lists of files in the pstore (eg. /sys/fs/pstore) - for certain file types (eg. dmesg) a handler is invoked - for all other files, the file is moved from pstore - In the case of dmesg handler, final processing occurs as such: - files processed in reverse lexigraphical order to faciliate reconstruction of original dmesg - the filename is examined to determine which dmesg it is a part - the file is appended to the reconstructed dmesg For example, the following pstore contents: root@vm356:~# ls -al /sys/fs/pstore total 0 drwxr-x--- 2 root root 0 May 9 09:50 . drwxr-xr-x 7 root root 0 May 9 09:50 .. -r--r--r-- 1 root root 1610 May 9 09:49 dmesg-efi-155741337601001 -r--r--r-- 1 root root 1778 May 9 09:49 dmesg-efi-155741337602001 -r--r--r-- 1 root root 1726 May 9 09:49 dmesg-efi-155741337603001 -r--r--r-- 1 root root 1746 May 9 09:49 dmesg-efi-155741337604001 -r--r--r-- 1 root root 1686 May 9 09:49 dmesg-efi-155741337605001 -r--r--r-- 1 root root 1690 May 9 09:49 dmesg-efi-155741337606001 -r--r--r-- 1 root root 1775 May 9 09:49 dmesg-efi-155741337607001 -r--r--r-- 1 root root 1811 May 9 09:49 dmesg-efi-155741337608001 -r--r--r-- 1 root root 1817 May 9 09:49 dmesg-efi-155741337609001 -r--r--r-- 1 root root 1795 May 9 09:49 dmesg-efi-155741337710001 -r--r--r-- 1 root root 1770 May 9 09:49 dmesg-efi-155741337711001 -r--r--r-- 1 root root 1796 May 9 09:49 dmesg-efi-155741337712001 -r--r--r-- 1 root root 1787 May 9 09:49 dmesg-efi-155741337713001 -r--r--r-- 1 root root 1808 May 9 09:49 dmesg-efi-155741337714001 -r--r--r-- 1 root root 1754 May 9 09:49 dmesg-efi-155741337715001 results in the following: root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/ total 92 drwxr-xr-x 2 root root 4096 May 9 09:50 . drwxr-xr-x 4 root root 40 May 9 09:50 .. -rw-r--r-- 1 root root 1610 May 9 09:50 dmesg-efi-155741337601001 -rw-r--r-- 1 root root 1778 May 9 09:50 dmesg-efi-155741337602001 -rw-r--r-- 1 root root 1726 May 9 09:50 dmesg-efi-155741337603001 -rw-r--r-- 1 root root 1746 May 9 09:50 dmesg-efi-155741337604001 -rw-r--r-- 1 root root 1686 May 9 09:50 dmesg-efi-155741337605001 -rw-r--r-- 1 root root 1690 May 9 09:50 dmesg-efi-155741337606001 -rw-r--r-- 1 root root 1775 May 9 09:50 dmesg-efi-155741337607001 -rw-r--r-- 1 root root 1811 May 9 09:50 dmesg-efi-155741337608001 -rw-r--r-- 1 root root 1817 May 9 09:50 dmesg-efi-155741337609001 -rw-r--r-- 1 root root 1795 May 9 09:50 dmesg-efi-155741337710001 -rw-r--r-- 1 root root 1770 May 9 09:50 dmesg-efi-155741337711001 -rw-r--r-- 1 root root 1796 May 9 09:50 dmesg-efi-155741337712001 -rw-r--r-- 1 root root 1787 May 9 09:50 dmesg-efi-155741337713001 -rw-r--r-- 1 root root 1808 May 9 09:50 dmesg-efi-155741337714001 -rw-r--r-- 1 root root 1754 May 9 09:50 dmesg-efi-155741337715001 -rw-r--r-- 1 root root 26754 May 9 09:50 dmesg.txt where dmesg.txt is reconstructed from the group of related dmesg-efi-155741337* files. Configuration file: The pstore.conf configuration file has four settings, described below. - Storage : one of "none", "external", or "journal". With "none", this tool leaves the contents of pstore untouched. With "external", the contents of the pstore are moved into the /var/lib/systemd/pstore, as well as logged into the journal. With "journal", the contents of the pstore are recorded only in the systemd journal. The default is "external". - Unlink : is a boolean. When "true", the default, then files in the pstore are removed once processed. When "false", processing of the pstore occurs normally, but the pstore files remain. References: [1] "Persistent storage for a kernel's dying breath", March 23, 2011. https://lwn.net/Articles/434821/ [2] "Advanced Configuration and Power Interface Specification", version 6.2, May 2017. https://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf [3] "Unified Extensible Firmware Interface Specification", version 2.8, March 2019. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf [4] "The kernel’s command-line parameters", https://static.lwn.net/kerneldoc/admin-guide/kernel-parameters.html
2019-05-16 15:59:01 +02:00
['systemd-pstore.service', 'ENABLE_PSTORE'],
['systemd-fsck-root.service', ''],
['systemd-fsck@.service', ''],
['systemd-hibernate-resume@.service', 'ENABLE_HIBERNATE'],
['systemd-hibernate.service', 'ENABLE_HIBERNATE'],
['systemd-hybrid-sleep.service', 'ENABLE_HIBERNATE'],
['systemd-suspend-then-hibernate.service', 'ENABLE_HIBERNATE'],
['systemd-hostnamed.service', 'ENABLE_HOSTNAMED',
'dbus-org.freedesktop.hostname1.service'],
['systemd-hwdb-update.service', 'ENABLE_HWDB',
'sysinit.target.wants/'],
['systemd-importd.service', 'ENABLE_IMPORTD',
'dbus-org.freedesktop.import1.service'],
['systemd-initctl.service', 'HAVE_SYSV_COMPAT'],
['systemd-journal-gatewayd.service', 'ENABLE_REMOTE HAVE_MICROHTTPD'],
['systemd-journal-remote.service', 'ENABLE_REMOTE HAVE_MICROHTTPD'],
['systemd-journal-upload.service', 'ENABLE_REMOTE HAVE_LIBCURL'],
['systemd-journald.service', '',
'sysinit.target.wants/'],
['systemd-journald@.service', ''],
['systemd-localed.service', 'ENABLE_LOCALED',
'dbus-org.freedesktop.locale1.service'],
['systemd-logind.service', 'ENABLE_LOGIND',
'multi-user.target.wants/ dbus-org.freedesktop.login1.service'],
['systemd-machined.service', 'ENABLE_MACHINED',
'dbus-org.freedesktop.machine1.service'],
['systemd-modules-load.service', 'HAVE_KMOD',
'sysinit.target.wants/'],
['systemd-network-generator.service', 'ENABLE_NETWORKD'],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['systemd-networkd.service', 'ENABLE_NETWORKD'],
['systemd-networkd-wait-online.service', 'ENABLE_NETWORKD'],
['systemd-nspawn@.service', ''],
2020-06-19 20:41:03 +02:00
['systemd-oomd.service', 'ENABLE_OOMD'],
['systemd-portabled.service', 'ENABLE_PORTABLED',
'dbus-org.freedesktop.portable1.service'],
['systemd-userdbd.service', 'ENABLE_USERDB'],
['systemd-homed.service', 'ENABLE_HOMED'],
['systemd-quotacheck.service', 'ENABLE_QUOTACHECK'],
['systemd-random-seed.service', 'ENABLE_RANDOMSEED',
'sysinit.target.wants/'],
['systemd-remount-fs.service', ''],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['systemd-resolved.service', 'ENABLE_RESOLVE'],
['systemd-rfkill.service', 'ENABLE_RFKILL'],
['systemd-suspend.service', ''],
['systemd-sysctl.service', '',
'sysinit.target.wants/'],
['systemd-timedated.service', 'ENABLE_TIMEDATED',
'dbus-org.freedesktop.timedate1.service'],
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
['systemd-timesyncd.service', 'ENABLE_TIMESYNCD'],
['systemd-time-wait-sync.service', 'ENABLE_TIMESYNCD'],
['systemd-udevd.service', '',
'sysinit.target.wants/'],
['systemd-update-done.service', '',
'sysinit.target.wants/'],
['systemd-update-utmp-runlevel.service', 'ENABLE_UTMP HAVE_SYSV_COMPAT',
'multi-user.target.wants/ graphical.target.wants/ rescue.target.wants/'],
['systemd-update-utmp.service', 'ENABLE_UTMP',
'sysinit.target.wants/'],
['systemd-user-sessions.service', 'HAVE_PAM',
'multi-user.target.wants/'],
['systemd-vconsole-setup.service', 'ENABLE_VCONSOLE'],
2020-04-08 23:59:13 +02:00
['systemd-volatile-root.service', 'ENABLE_INITRD'],
['systemd-repart.service', 'ENABLE_REPART',
'sysinit.target.wants/ initrd-root-fs.target.wants/'],
['user-runtime-dir@.service', ''],
['user@.service', ''],
]
m4_units = [
['console-getty.service', ''],
['container-getty@.service', ''],
['getty@.service', '',
meson: stop creating enablement symlinks in /etc during installation This patch was initially prompted by a report on a Fedora update [1], that the upgrade causes systemd-resolved.service and systemd-networkd.service to be re-enabled. We generally want to preserve the enablement of all services during upgrades, so a reset like this is not expected. Both services declare two symlinks in their [Install] sections, for their dbus names and for multi-user.target.wants/. It turns out that both services were only partially enabled, because their dbus unit symlinks /etc/systemd/system/dbus-org.freedesktop.{resolve1,network1}.service were created, by the symlinks in /etc/systemd/system/multi-user.target.wants/ were not. This means that the units could be activated by dbus, but not in usual fashion using systemctl start. Our tools make it rather hard to figure out when something like this happens, and it is definitely an area for improvement on its own. The symlink in .wants/ was filtered out by during packaging, but the dbus symlink was left in (I assume by mistake). Let's simplify things by not creating the symlinks statically during 'ninja install'. This means that the units shipped by systemd have to be enabled in the usual fashion, which in turns means that [Install] section and presets become the "single source of truth" and we don't have two sets of conflicting configuration. Let's consider a few cases: - developer: a developer installs systemd from git on a running system, and they don't want the installation to reset enablement of anything. So this change is either positive for them, or has no effect (if they have everything at defaults). - package creation: we want to create symlinks using 'preset-all' and 'preset' on upgraded packages, we don't want to have any static symlinks. This change will remove the need to filter out symlinks in packaging and of course fix the original report. - installation of systemd from scratch: this change means that without 'preset-all' the system will not be functional. This case could be affected negatively by this change, but I think it's enough of a corner case to accept this. In practice I expect people to build a package, not installl directly into the file system, so this might not even matter in practice. Creating those symlinks was probably the right thing in the beginning, but nowadays the preset system is very well established and people expect it to be honoured. Ignoring the presets and doing static configuration is not welcome anymore. Note: during package installation, either 'preset-all' or 'preset getty@.service machines.target remote-cryptsetup.target remote-fs.target systemd-networkd.service systemd-resolved.service systemd-networkd-wait-online.service systemd-timesyncd.service' should be called. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-616045ca76
2019-04-01 13:57:24 +02:00
'autovt@.service '],
['serial-getty@.service', ''],
]
meson: Optimize add-wants targets Instead of invoking meson-add-wants.sh once for each wants that has to be added, we pass all wants to a single invocation of meson-add-wants.sh and in meson-add-wants.sh, loop over the arguments. This saves about 300ms on the install step. Before: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.465s user 0m1.025s sys 0m0.426s ``` After: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.162s user 0m0.803s sys 0m0.338s ```
2021-01-09 20:48:39 +01:00
add_wants = []
foreach tuple : in_units
file = tuple[0]
# we do this here because install_data does not accept custom_target output
conds = tuple[1].split(' ')
install = ((conds.get(0, '') == '' or conf.get(conds[0]) == 1) and
(conds.get(1, '') == '' or conf.get(conds[1]) == 1))
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
gen1 = configure_file(
input : file + '.in',
output : file + '.tmp',
configuration : substs)
gen2 = custom_target(
file,
input : gen1,
output : file,
command : [sed, '/^## /d', '@INPUT@'],
capture : true,
install : install,
install_dir : systemunitdir)
if install and tuple.length() > 2
foreach target : tuple[2].split()
meson: Optimize add-wants targets Instead of invoking meson-add-wants.sh once for each wants that has to be added, we pass all wants to a single invocation of meson-add-wants.sh and in meson-add-wants.sh, loop over the arguments. This saves about 300ms on the install step. Before: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.465s user 0m1.025s sys 0m0.426s ``` After: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.162s user 0m0.803s sys 0m0.338s ```
2021-01-09 20:48:39 +01:00
add_wants += [systemunitdir, target, file]
endforeach
endif
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
endforeach
foreach tuple : m4_units
file = tuple[0]
input = tuple.get(3, file + '.m4')
# we do this here because install_data does not accept custom_target output
conds = tuple[1].split(' ')
install = ((conds.get(0, '') == '' or conf.get(conds[0]) == 1) and
(conds.get(1, '') == '' or conf.get(conds[1]) == 1))
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
custom_target(
file,
input : input,
output: file,
command : [meson_apply_m4, config_h, '@INPUT@'],
capture : true,
install : install,
install_dir : systemunitdir)
if tuple.length() > 2 and install
foreach target : tuple[2].split()
meson: Optimize add-wants targets Instead of invoking meson-add-wants.sh once for each wants that has to be added, we pass all wants to a single invocation of meson-add-wants.sh and in meson-add-wants.sh, loop over the arguments. This saves about 300ms on the install step. Before: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.465s user 0m1.025s sys 0m0.426s ``` After: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.162s user 0m0.803s sys 0m0.338s ```
2021-01-09 20:48:39 +01:00
add_wants += [systemunitdir, target, file]
endforeach
endif
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
endforeach
foreach tuple : units
file = tuple[0]
input = tuple.get(3, file)
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
conds = tuple[1].split(' ')
install = ((conds.get(0, '') == '' or conf.get(conds[0]) == 1) and
(conds.get(1, '') == '' or conf.get(conds[1]) == 1))
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
if install
install_data(input,
install_dir : systemunitdir)
if tuple.length() > 2
foreach target : tuple[2].split()
meson: Optimize add-wants targets Instead of invoking meson-add-wants.sh once for each wants that has to be added, we pass all wants to a single invocation of meson-add-wants.sh and in meson-add-wants.sh, loop over the arguments. This saves about 300ms on the install step. Before: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.465s user 0m1.025s sys 0m0.426s ``` After: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.162s user 0m0.803s sys 0m0.338s ```
2021-01-09 20:48:39 +01:00
add_wants += [systemunitdir, target, file]
endforeach
endif
endif
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
endforeach
meson: Optimize add-wants targets Instead of invoking meson-add-wants.sh once for each wants that has to be added, we pass all wants to a single invocation of meson-add-wants.sh and in meson-add-wants.sh, loop over the arguments. This saves about 300ms on the install step. Before: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.465s user 0m1.025s sys 0m0.426s ``` After: ``` ‣ Running build script... [1/418] Generating version.h with a custom command Installing /root/build/po/be.gmo to /root/dest/usr/share/locale/be/LC_MESSAGES/systemd.mo Installing /root/build/po/be@latin.gmo to /root/dest/usr/share/locale/be@latin/LC_MESSAGES/systemd.mo Installing /root/build/po/bg.gmo to /root/dest/usr/share/locale/bg/LC_MESSAGES/systemd.mo Installing /root/build/po/ca.gmo to /root/dest/usr/share/locale/ca/LC_MESSAGES/systemd.mo Installing /root/build/po/cs.gmo to /root/dest/usr/share/locale/cs/LC_MESSAGES/systemd.mo Installing /root/build/po/da.gmo to /root/dest/usr/share/locale/da/LC_MESSAGES/systemd.mo Installing /root/build/po/de.gmo to /root/dest/usr/share/locale/de/LC_MESSAGES/systemd.mo Installing /root/build/po/el.gmo to /root/dest/usr/share/locale/el/LC_MESSAGES/systemd.mo Installing /root/build/po/es.gmo to /root/dest/usr/share/locale/es/LC_MESSAGES/systemd.mo Installing /root/build/po/fr.gmo to /root/dest/usr/share/locale/fr/LC_MESSAGES/systemd.mo Installing /root/build/po/gl.gmo to /root/dest/usr/share/locale/gl/LC_MESSAGES/systemd.mo Installing /root/build/po/hr.gmo to /root/dest/usr/share/locale/hr/LC_MESSAGES/systemd.mo Installing /root/build/po/hu.gmo to /root/dest/usr/share/locale/hu/LC_MESSAGES/systemd.mo Installing /root/build/po/id.gmo to /root/dest/usr/share/locale/id/LC_MESSAGES/systemd.mo Installing /root/build/po/it.gmo to /root/dest/usr/share/locale/it/LC_MESSAGES/systemd.mo Installing /root/build/po/ja.gmo to /root/dest/usr/share/locale/ja/LC_MESSAGES/systemd.mo Installing /root/build/po/ko.gmo to /root/dest/usr/share/locale/ko/LC_MESSAGES/systemd.mo Installing /root/build/po/lt.gmo to /root/dest/usr/share/locale/lt/LC_MESSAGES/systemd.mo Installing /root/build/po/pl.gmo to /root/dest/usr/share/locale/pl/LC_MESSAGES/systemd.mo Installing /root/build/po/pt_BR.gmo to /root/dest/usr/share/locale/pt_BR/LC_MESSAGES/systemd.mo Installing /root/build/po/ro.gmo to /root/dest/usr/share/locale/ro/LC_MESSAGES/systemd.mo Installing /root/build/po/ru.gmo to /root/dest/usr/share/locale/ru/LC_MESSAGES/systemd.mo Installing /root/build/po/sk.gmo to /root/dest/usr/share/locale/sk/LC_MESSAGES/systemd.mo Installing /root/build/po/sr.gmo to /root/dest/usr/share/locale/sr/LC_MESSAGES/systemd.mo Installing /root/build/po/sv.gmo to /root/dest/usr/share/locale/sv/LC_MESSAGES/systemd.mo Installing /root/build/po/tr.gmo to /root/dest/usr/share/locale/tr/LC_MESSAGES/systemd.mo Installing /root/build/po/uk.gmo to /root/dest/usr/share/locale/uk/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_CN.gmo to /root/dest/usr/share/locale/zh_CN/LC_MESSAGES/systemd.mo Installing /root/build/po/zh_TW.gmo to /root/dest/usr/share/locale/zh_TW/LC_MESSAGES/systemd.mo Installing /root/build/po/pa.gmo to /root/dest/usr/share/locale/pa/LC_MESSAGES/systemd.mo real 0m1.162s user 0m0.803s sys 0m0.338s ```
2021-01-09 20:48:39 +01:00
meson.add_install_script('meson-add-wants.sh', add_wants)
install_data('user-.slice.d/10-defaults.conf',
install_dir : systemunitdir + '/user-.slice.d')
############################################################
if install_sysconfdir
meson.add_install_script(meson_make_symlink,
join_paths(pkgsysconfdir, 'user'),
join_paths(sysconfdir, 'xdg/systemd/user'))
endif
meson.add_install_script(meson_make_symlink,
join_paths(dbussystemservicedir, 'org.freedesktop.systemd1.service'),
join_paths(dbussessionservicedir, 'org.freedesktop.systemd1.service'))
if conf.get('HAVE_SYSV_COMPAT') == 1
foreach i : [1, 2, 3, 4, 5]
meson.add_install_script(
'sh', '-c',
mkdir_p
.format(join_paths(systemunitdir, 'runlevel@0@.target.wants'.format(i))))
endforeach
endif
meson: build systemd using meson It's crucial that we can build systemd using VS2010! ... er, wait, no, that's not the official reason. We need to shed old systems by requring python 3! Oh, no, it's something else. Maybe we need to throw out 345 years of knowlege accumulated in autotools? Whatever, this new thing is cool and shiny, let's use it. This is not complete, I'm throwing it out here for your amusement and critique. - rules for sd-boot are missing. Those might be quite complicated. - rules for tests are missing too. Those are probably quite simple and repetitive, but there's lots of them. - it's likely that I didn't get all the conditions right, I only tested "full" compilation where most deps are provided and nothing is disabled. - busname.target and all .busname units are skipped on purpose. Otherwise, installation into $DESTDIR has the same list of files and the autoconf install, except for .la files. It'd be great if people had a careful look at all the library linking options. I added stuff until things compiled, and in the end there's much less linking then in the old system. But it seems that there's still a lot of unnecessary deps. meson has a `shared_module` statement, which sounds like something appropriate for our nss and pam modules. Unfortunately, I couldn't get it to work. For the nss modules, we need an .so version of '2', but `shared_module` disallows the version argument. For the pam module, it also didn't work, I forgot the reason. The handling of .m4 and .in and .m4.in files is rather awkward. It's likely that this could be simplified. If make support is ever dropped, I think it'd make sense to switch to a different templating system so that two different languages and not required, which would make everything simpler yet. v2: - use get_pkgconfig_variable - use sh not bash - use add_project_arguments v3: - drop required:true and fix progs/prog typo v4: - use find_library('bz2') - add TTY_GID definition - define __SANE_USERSPACE_TYPES__ - use join_paths(prefix, ...) is used on all paths to make them all absolute v5: - replace all declare_dependency's with [] - add more conf.get guards around optional components v6: - drop -pipe, -Wall which are the default in meson - use compiler.has_function() and compiler.has_header_symbol instead of the hand-rolled checks. - fix duplication in 'liblibsystemd' library name - use the right .sym file for pam_systemd - rename 'compiler' to 'cc': shorter, and more idiomatic. v7: - use ENABLE_ENVIRONMENT_D not HAVE_ENVIRONMENT_D - rename prefix to prefixdir, rootprefix to rootprefixdir ("prefix" is too common of a name and too easy to overwrite by mistake) - wrap more stuff with conf.get('ENABLE...') == 1 - use rootprefix=='/' and rootbindir as install_dir, to fix paths under split-usr==true. v8: - use .split() also for src/coredump. Now everything is consistent ;) - add rootlibdir option and use it on the libraries that require it v9: - indentation v10: - fix check for qrencode and libaudit v11: - unify handling of executable paths, provide options for all progs This makes the meson build behave slightly differently than the autoconf-based one, because we always first try to find the executable in the filesystem, and fall back to the default. I think different handling of loadkeys, setfont, and telinit was just a historical accident. In addition to checking in $PATH, also check /usr/sbin/, /sbin for programs. In Fedora $PATH includes /usr/sbin, (and /sbin is is a symlink to /usr/sbin), but in Debian, those directories are not included in the path. C.f. https://github.com/mesonbuild/meson/issues/1576. - call all the options 'xxx-path' for clarity. - sort man/rules/meson.build properly so it's stable
2017-04-05 05:03:47 +02:00
subdir('user')