2018-10-19 15:45:15 +00:00
|
|
|
project(
|
2019-02-15 15:36:30 +00:00
|
|
|
'toolbox',
|
2021-11-13 02:17:39 +00:00
|
|
|
'c',
|
2021-12-10 02:28:35 +00:00
|
|
|
version: '0.0.99.3',
|
2018-10-19 15:45:15 +00:00
|
|
|
license: 'ASL 2.0',
|
2021-12-01 03:25:38 +00:00
|
|
|
meson_version: '>= 0.58.0',
|
2018-10-19 15:45:15 +00:00
|
|
|
)
|
|
|
|
|
|
build: Call 'systemd-tmpfiles --create' when installing
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9
https://github.com/containers/toolbox/issues/955
2021-12-17 16:45:43 +00:00
|
|
|
fs = import('fs')
|
|
|
|
|
|
2021-11-13 02:17:39 +00:00
|
|
|
cc = meson.get_compiler('c')
|
2021-11-13 03:08:27 +00:00
|
|
|
if not cc.has_argument('-print-file-name=libc.so')
|
|
|
|
|
error('C compiler does not support the -print-file-name argument.')
|
|
|
|
|
endif
|
2021-11-13 02:17:39 +00:00
|
|
|
|
2020-05-13 21:34:00 +00:00
|
|
|
go = find_program('go')
|
2019-02-28 17:07:24 +00:00
|
|
|
go_md2man = find_program('go-md2man')
|
2019-04-10 12:03:15 +00:00
|
|
|
shellcheck = find_program('shellcheck', required: false)
|
2021-03-21 21:58:23 +00:00
|
|
|
skopeo = find_program('skopeo', required: false)
|
2019-04-24 17:36:36 +00:00
|
|
|
|
2021-03-21 21:58:23 +00:00
|
|
|
bash_completion = dependency('bash-completion', required: false)
|
2021-11-21 14:16:07 +00:00
|
|
|
fish = dependency('fish', required: false)
|
2021-03-21 21:58:23 +00:00
|
|
|
|
build: Add an option for the migration path for coreos/toolbox users
Commit 6c86cabbe5da6e542b changed the command line interface to behave
a lot similar to that of github.com/coreos/toolbox, which makes things
easier for those switching over from it.
However, it makes things confusing for the vast majority of users who
have never used coreos/toolbox. The Toolbox CLI aims to be friendly to
new users by being self-documenting and offering a smooth onboarding
experience. It's jarring to new users when 'toolbox', without any
commands specified, suggests that it needs to perform a big download.
It's difficult to document two different sets of CLIs, and if the
manuals don't mention the second behaviour, then it just leaves the
users even more confused.
Hence, it will be good to keep the migration path for coreos/toolbox
behind a build-time option, so that only those OS distributors who
truly need it may enable it without impacting others. Fortunately,
coreos/toolbox doesn't have any manuals, which means that there's no
need to conditionalize the documentation.
This commit merely adds the build-time option. Subsequent commits will
use this to actually conditionalize the code.
https://github.com/containers/toolbox/pull/951
2021-11-13 12:55:10 +00:00
|
|
|
migration_path_for_coreos_toolbox = get_option('migration_path_for_coreos_toolbox')
|
2021-03-21 21:58:23 +00:00
|
|
|
profiledir = get_option('profile_dir')
|
2021-07-05 01:46:07 +00:00
|
|
|
|
|
|
|
|
tmpfilesdir = get_option('tmpfiles_dir')
|
build: Call 'systemd-tmpfiles --create' when installing
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9
https://github.com/containers/toolbox/issues/955
2021-12-17 16:45:43 +00:00
|
|
|
if tmpfilesdir == '' or not fs.exists('/run/.containerenv')
|
2021-07-05 01:46:07 +00:00
|
|
|
systemd_dep = dependency('systemd')
|
build: Call 'systemd-tmpfiles --create' when installing
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9
https://github.com/containers/toolbox/issues/955
2021-12-17 16:45:43 +00:00
|
|
|
|
|
|
|
|
if tmpfilesdir == ''
|
|
|
|
|
tmpfilesdir = systemd_dep.get_variable(pkgconfig: 'tmpfilesdir')
|
|
|
|
|
endif
|
2021-07-05 01:46:07 +00:00
|
|
|
endif
|
Give access to removable devices and other temporary mounts
Currently, when udisks is configured to use /run/media instead of
/media, on most operating systems, the /run/media directory is created
by udisks itself when the first mount is handled [1]. This causes
problems when creating the toolbox container, if nothing has been
mounted after the current boot, because a missing directory cannot be
bind mounted.
Fedora Silverblue is a significant exception to the above, where
rpm-ostree takes care of creating /run/media with systemd-tmpfiles [2]
during boot.
The correct long-term solution is to get udisks to create /run/media
during boot with systemd-tmpfiles by installing a snippet in
tmpfiles.d [3, 4]. Until that happens, and is widely deployed, the
toolbox needs to provide the snippet itself to make things work on
the majority of operating systems.
Note that, in case udisks is configured to use /media instead of
/run/media, then this will create an unused /run/media directory. This
is probably fine because /run/media is the default setting for udisks.
Moreover, an unused directory is way better than not being able to
access mount points from a toolbox container or having 'podman create'
fail due to a missing directory.
Based on 4a2a15f2eb3a6b810fcf9b699272fcc9a7871c6e and as suggested by
Daniel J Walsh.
[1] UDisks commit aa02e5fc53efdeaf
https://github.com/storaged-project/udisks/commit/aa02e5fc53efdeaf
[2] rpm-ostree commit 958dfa435e4e4a3e
https://github.com/projectatomic/rpm-ostree/commit/958dfa435e4e4a3e
[3] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
[4] https://github.com/storaged-project/udisks/pull/641
https://github.com/debarshiray/toolbox/issues/3
2019-03-12 17:45:19 +00:00
|
|
|
|
2022-08-29 19:59:08 +00:00
|
|
|
toolbox = files('toolbox')
|
|
|
|
|
|
|
|
|
|
if shellcheck.found()
|
|
|
|
|
test('shellcheck', shellcheck, args: [toolbox])
|
|
|
|
|
endif
|
|
|
|
|
|
2021-03-21 21:58:23 +00:00
|
|
|
if not skopeo.found()
|
|
|
|
|
message('Running system tests requires Skopeo for OCI image manipulation.')
|
|
|
|
|
endif
|
|
|
|
|
|
2020-07-23 15:17:38 +00:00
|
|
|
install_subdir(
|
|
|
|
|
'test',
|
2021-07-09 12:05:26 +00:00
|
|
|
install_dir: join_paths(get_option('datadir'), meson.project_name()),
|
|
|
|
|
exclude_files: [
|
|
|
|
|
'system/libs/bats-assert/.git',
|
|
|
|
|
'system/libs/bats-assert/.gitignore',
|
|
|
|
|
'system/libs/bats-assert/.travis.yml',
|
|
|
|
|
'system/libs/bats-assert/package.json',
|
|
|
|
|
'system/libs/bats-support/.git',
|
|
|
|
|
'system/libs/bats-support/.gitignore',
|
|
|
|
|
'system/libs/bats-support/.travis.yml',
|
|
|
|
|
'system/libs/bats-support/package.json'
|
|
|
|
|
],
|
|
|
|
|
exclude_directories: [
|
|
|
|
|
'system/libs/bats-assert/.git',
|
|
|
|
|
'system/libs/bats-assert/script',
|
|
|
|
|
'system/libs/bats-assert/test',
|
|
|
|
|
'system/libs/bats-support/.git',
|
|
|
|
|
'system/libs/bats-support/script',
|
|
|
|
|
'system/libs/bats-support/test'
|
|
|
|
|
]
|
2020-07-23 15:17:38 +00:00
|
|
|
)
|
|
|
|
|
|
Give access to removable devices and other temporary mounts
Currently, when udisks is configured to use /run/media instead of
/media, on most operating systems, the /run/media directory is created
by udisks itself when the first mount is handled [1]. This causes
problems when creating the toolbox container, if nothing has been
mounted after the current boot, because a missing directory cannot be
bind mounted.
Fedora Silverblue is a significant exception to the above, where
rpm-ostree takes care of creating /run/media with systemd-tmpfiles [2]
during boot.
The correct long-term solution is to get udisks to create /run/media
during boot with systemd-tmpfiles by installing a snippet in
tmpfiles.d [3, 4]. Until that happens, and is widely deployed, the
toolbox needs to provide the snippet itself to make things work on
the majority of operating systems.
Note that, in case udisks is configured to use /media instead of
/run/media, then this will create an unused /run/media directory. This
is probably fine because /run/media is the default setting for udisks.
Moreover, an unused directory is way better than not being able to
access mount points from a toolbox container or having 'podman create'
fail due to a missing directory.
Based on 4a2a15f2eb3a6b810fcf9b699272fcc9a7871c6e and as suggested by
Daniel J Walsh.
[1] UDisks commit aa02e5fc53efdeaf
https://github.com/storaged-project/udisks/commit/aa02e5fc53efdeaf
[2] rpm-ostree commit 958dfa435e4e4a3e
https://github.com/projectatomic/rpm-ostree/commit/958dfa435e4e4a3e
[3] https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
[4] https://github.com/storaged-project/udisks/pull/641
https://github.com/debarshiray/toolbox/issues/3
2019-03-12 17:45:19 +00:00
|
|
|
subdir('data')
|
2019-02-28 17:07:24 +00:00
|
|
|
subdir('doc')
|
2019-04-24 17:36:36 +00:00
|
|
|
subdir('profile.d')
|
2020-05-08 11:29:18 +00:00
|
|
|
subdir('src')
|
2021-11-21 14:16:07 +00:00
|
|
|
if get_option('install_completions')
|
|
|
|
|
subdir('completion')
|
|
|
|
|
endif
|
build: Call 'systemd-tmpfiles --create' when installing
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9
https://github.com/containers/toolbox/issues/955
2021-12-17 16:45:43 +00:00
|
|
|
|
|
|
|
|
meson.add_install_script('meson_post_install.py')
|