2017-11-18 18:32:01 +01:00
# SPDX-License-Identifier: LGPL-2.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-04 23:03:47 -04:00
units = [
2017-04-17 19:25:00 -04:00
[ 'basic.target' , '' ] ,
[ 'bluetooth.target' , '' ] ,
2018-06-22 12:52:28 +02:00
[ 'boot-complete.target' , '' ] ,
2017-04-17 19:25:00 -04:00
[ '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' , '' ] ,
[ 'getty.target' , '' ,
'multi-user.target.wants/' ] ,
2017-08-31 11:20:14 +02:00
[ 'getty-pre.target' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'graphical.target' , '' ,
'runlevel5.target default.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' ] ,
2017-04-17 19:25:00 -04:00
[ 'initrd-fs.target' , '' ] ,
[ 'initrd-root-device.target' , '' ] ,
[ 'initrd-root-fs.target' , '' ] ,
[ 'initrd-switch-root.target' , '' ] ,
[ 'initrd.target' , '' ] ,
[ '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' ] ,
2017-04-17 19:25:00 -04:00
[ 'multi-user.target' , '' ,
'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' , '' ,
'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' , '' ,
'runlevel6.target ctrl-alt-del.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-cryptsetup.target' , 'HAVE_LIBCRYPTSETUP' ] ,
2017-04-17 19:25:00 -04:00
[ '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' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'rescue.target' , '' ,
'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/' ] ,
[ 'sysinit.target' , '' ] ,
[ 'syslog.socket' , '' ] ,
[ 'system-update.target' , '' ] ,
2018-06-19 10:50:41 +02:00
[ 'system-update-pre.target' , '' ] ,
2018-04-18 02:49:10 +09:00
[ 'system-update-cleanup.service' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-ask-password-console.path' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-ask-password-wall.path' , '' ,
'multi-user.target.wants/' ] ,
[ 'systemd-coredump.socket' , 'ENABLE_COREDUMP' ,
'sockets.target.wants/' ] ,
2018-10-16 16:34:45 +02:00
[ 'systemd-exit.service' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-initctl.socket' , '' ,
'sockets.target.wants/' ] ,
2017-04-27 17:47:04 +00:00
[ 'systemd-journal-gatewayd.socket' , 'ENABLE_REMOTE HAVE_MICROHTTPD' ] ,
[ 'systemd-journal-remote.socket' , 'ENABLE_REMOTE HAVE_MICROHTTPD' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-journald-audit.socket' , '' ,
'sockets.target.wants/' ] ,
[ 'systemd-journald-dev-log.socket' , '' ,
'sockets.target.wants/' ] ,
[ 'systemd-journald.socket' , '' ,
'sockets.target.wants/' ] ,
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' ] ,
2018-10-16 15:34:57 +02:00
[ 'systemd-poweroff.service' , '' ] ,
2018-10-16 15:30:53 +02:00
[ 'systemd-reboot.service' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-rfkill.socket' , 'ENABLE_RFKILL' ] ,
[ 'systemd-tmpfiles-clean.timer' , '' ,
'timers.target.wants/' ] ,
[ 'systemd-udevd-control.socket' , '' ,
'sockets.target.wants/' ] ,
[ 'systemd-udevd-kernel.socket' , '' ,
'sockets.target.wants/' ] ,
[ 'time-sync.target' , '' ] ,
[ 'timers.target' , '' ] ,
2017-08-09 22:13:41 +09:00
[ 'tmp.mount' , '' ,
'local-fs.target.wants/' ] ,
2017-04-17 19:25:00 -04:00
[ 'umount.target' , '' ] ,
[ 'user.slice' , '' ] ,
2017-06-21 16:04:38 -04:00
[ 'var-lib-machines.mount' , 'ENABLE_MACHINED' ,
'remote-fs.target.wants/ machines.target.wants/' ] ,
2017-04-12 20:58:55 -04:00
]
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-04 23:03:47 -04:00
in_units = [
2017-04-17 19:25:00 -04:00
[ 'debug-shell.service' , '' ] ,
[ 'emergency.service' , '' ] ,
[ 'halt-local.service' , 'HAVE_SYSV_COMPAT' ] ,
[ 'initrd-cleanup.service' , '' ] ,
[ 'initrd-parse-etc.service' , '' ] ,
[ 'initrd-switch-root.service' , '' ] ,
[ 'initrd-udevadm-cleanup-db.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-ask-password-console.service' , '' ] ,
[ 'systemd-ask-password-wall.service' , '' ] ,
[ 'systemd-backlight@.service' , 'ENABLE_BACKLIGHT' ] ,
[ 'systemd-binfmt.service' , 'ENABLE_BINFMT' ,
'sysinit.target.wants/' ] ,
2018-06-25 17:24:09 +02:00
[ 'systemd-bless-boot.service' , 'ENABLE_EFI HAVE_BLKID' ] ,
2018-06-25 16:07:33 +02:00
[ 'systemd-boot-check-no-failures.service' , '' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-coredump@.service' , 'ENABLE_COREDUMP' ] ,
[ 'systemd-firstboot.service' , 'ENABLE_FIRSTBOOT' ,
'sysinit.target.wants/' ] ,
[ 'systemd-fsck-root.service' , '' ] ,
[ 'systemd-fsck@.service' , '' ] ,
[ 'systemd-halt.service' , '' ] ,
[ 'systemd-hibernate-resume@.service' , 'ENABLE_HIBERNATE' ] ,
[ 'systemd-hibernate.service' , 'ENABLE_HIBERNATE' ] ,
[ 'systemd-hybrid-sleep.service' , 'ENABLE_HIBERNATE' ] ,
2018-03-28 11:00:06 -05:00
[ 'systemd-suspend-then-hibernate.service' , 'ENABLE_HIBERNATE' ] ,
2017-04-17 19:25:00 -04:00
[ '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' , '' ] ,
[ 'systemd-journal-catalog-update.service' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-journal-flush.service' , '' ,
'sysinit.target.wants/' ] ,
[ '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-kexec.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-machine-id-commit.service' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-machined.service' , 'ENABLE_MACHINED' ,
'dbus-org.freedesktop.machine1.service' ] ,
[ 'systemd-modules-load.service' , 'HAVE_KMOD' ,
'sysinit.target.wants/' ] ,
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' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-nspawn@.service' , '' ] ,
2018-04-16 21:41:40 +02:00
[ 'systemd-portabled.service' , 'ENABLE_PORTABLED' ,
'dbus-org.freedesktop.portable1.service' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-quotacheck.service' , 'ENABLE_QUOTACHECK' ] ,
[ 'systemd-random-seed.service' , 'ENABLE_RANDOMSEED' ,
'sysinit.target.wants/' ] ,
2018-12-20 15:52:52 +01:00
[ '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' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-rfkill.service' , 'ENABLE_RFKILL' ] ,
[ 'systemd-suspend.service' , '' ] ,
[ 'systemd-sysctl.service' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-sysusers.service' , 'ENABLE_SYSUSERS' ,
'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' ] ,
2018-04-10 11:05:25 -05:00
[ 'systemd-time-wait-sync.service' , 'ENABLE_TIMESYNCD' ] ,
2017-04-17 19:25:00 -04:00
[ 'systemd-tmpfiles-clean.service' , 'ENABLE_TMPFILES' ] ,
[ 'systemd-tmpfiles-setup-dev.service' , 'ENABLE_TMPFILES' ,
'sysinit.target.wants/' ] ,
[ 'systemd-tmpfiles-setup.service' , 'ENABLE_TMPFILES' ,
'sysinit.target.wants/' ] ,
[ 'systemd-udev-settle.service' , '' ] ,
[ 'systemd-udev-trigger.service' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-udevd.service' , '' ,
'sysinit.target.wants/' ] ,
[ 'systemd-update-done.service' , '' ,
'sysinit.target.wants/' ] ,
2017-10-03 12:19:30 +02:00
[ 'systemd-update-utmp-runlevel.service' , 'ENABLE_UTMP HAVE_SYSV_COMPAT' ,
2017-04-17 19:25:00 -04:00
'multi-user.target.wants/ graphical.target.wants/ rescue.target.wants/' ] ,
2017-10-03 12:19:30 +02:00
[ 'systemd-update-utmp.service' , 'ENABLE_UTMP' ,
2017-04-17 19:25:00 -04:00
'sysinit.target.wants/' ] ,
2017-10-31 16:20:53 +09:00
[ 'systemd-user-sessions.service' , 'HAVE_PAM' ,
2017-04-17 19:25:00 -04:00
'multi-user.target.wants/' ] ,
[ 'systemd-vconsole-setup.service' , 'ENABLE_VCONSOLE' ] ,
[ 'systemd-volatile-root.service' , '' ] ,
2017-12-09 19:30:17 +01:00
[ 'user-runtime-dir@.service' , '' ] ,
2017-08-09 22:13:41 +09:00
[ 'user@.service' , '' ] ,
2017-04-12 20:58:55 -04:00
]
m4_units = [
2018-04-18 02:49:10 +09:00
[ 'console-getty.service' , '' ] ,
[ 'container-getty@.service' , '' ] ,
2017-04-17 19:25:00 -04:00
[ '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 ' ] ,
2017-04-17 19:25:00 -04:00
[ 'serial-getty@.service' , '' ] ,
2017-04-12 20:58:55 -04:00
]
2017-04-09 23:43:53 -04:00
foreach tuple : in_units
2017-04-17 19:25:00 -04:00
file = tuple [ 0 ]
2017-04-12 20:58:55 -04:00
2017-04-17 19:25:00 -04:00
# we do this here because install_data does not accept custom_target output
conds = tuple [ 1 ] . split ( ' ' )
2017-10-03 10:41:51 +02:00
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-04 23:03:47 -04:00
2017-04-17 19:25:00 -04: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 )
2017-04-09 23:43:53 -04:00
2017-04-17 19:25:00 -04:00
if install and tuple . length ( ) > 2
foreach target : tuple [ 2 ] . split ( )
meson . add_install_script ( 'meson-add-wants.sh' , 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-04 23:03:47 -04:00
endforeach
2017-04-09 23:43:53 -04:00
foreach tuple : m4_units
2017-04-17 19:25:00 -04:00
file = tuple [ 0 ]
input = tuple . get ( 3 , file + '.m4' )
2017-04-12 20:58:55 -04:00
2017-04-17 19:25:00 -04:00
# we do this here because install_data does not accept custom_target output
conds = tuple [ 1 ] . split ( ' ' )
2017-10-03 10:41:51 +02:00
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-04 23:03:47 -04:00
2017-04-17 19:25:00 -04:00
custom_target (
file ,
input : input ,
output : file ,
2018-05-07 18:17:35 +09:00
command : [ meson_apply_m4 , config_h , '@INPUT@' ] ,
2017-04-17 19:25:00 -04:00
capture : true ,
install : install ,
install_dir : systemunitdir )
2017-04-09 23:43:53 -04:00
2017-04-17 19:25:00 -04:00
if tuple . length ( ) > 2 and install
foreach target : tuple [ 2 ] . split ( )
meson . add_install_script ( 'meson-add-wants.sh' , 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-04 23:03:47 -04:00
endforeach
2017-04-12 20:58:55 -04:00
foreach tuple : units
2017-04-17 19:25:00 -04:00
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-04 23:03:47 -04:00
2017-04-17 19:25:00 -04:00
conds = tuple [ 1 ] . split ( ' ' )
2017-10-03 10:41:51 +02:00
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-04 23:03:47 -04:00
2017-04-17 19:25:00 -04:00
if install
install_data ( input ,
install_dir : systemunitdir )
2017-04-09 23:43:53 -04:00
2017-04-17 19:25:00 -04:00
if tuple . length ( ) > 2
foreach target : tuple [ 2 ] . split ( )
meson . add_install_script (
'meson-add-wants.sh' , 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-04 23:03:47 -04:00
endforeach
2017-12-07 22:25:26 +01:00
install_data ( 'user-.slice.d/10-defaults.conf' ,
install_dir : systemunitdir + '/user-.slice.d' )
2017-04-12 20:58:55 -04:00
############################################################
2017-04-09 23:55:50 -04:00
meson . add_install_script ( meson_make_symlink ,
2017-04-13 10:30:56 -04:00
join_paths ( pkgsysconfdir , 'user' ) ,
join_paths ( sysconfdir , 'xdg/systemd/user' ) )
2017-04-09 23:55:50 -04:00
meson . add_install_script ( meson_make_symlink ,
2017-04-13 10:30:56 -04:00
join_paths ( dbussystemservicedir , 'org.freedesktop.systemd1.service' ) ,
join_paths ( dbussessionservicedir , 'org.freedesktop.systemd1.service' ) )
2017-10-03 10:41:51 +02:00
if conf . get ( 'HAVE_SYSV_COMPAT' ) == 1
2017-04-17 19:25:00 -04:00
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
2017-04-09 23:55:05 -04:00
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-04 23:03:47 -04:00
subdir ( 'user' )