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')
|
2022-10-24 11:27:24 +00:00
|
|
|
|
|
|
|
|
codespell = find_program('codespell', required: false)
|
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
|
|
|
|
build: Enable changing the completion paths & drop install_completions
The bash-completion and fish dependencies were already optional - the
shell completions for Bash and fish won't be generated and installed if
they are absent; and there's no dependency required for Z shell. So the
install_completions build option wasn't reducing the dependency burden.
The build option was a way to disable the generation and installation of
the shell completions, regardless of whether the necessary dependencies
are present or not. The only use-case for this is when installing to a
non-system-wide prefix while hacking on Toolbox as a non-root user,
because the locations for the completions advertised by the shells' APIs
might not be accessible. Being able to disable the completions prevents
the installation from failing.
A different way of ensuring a smooth developer experience for a Toolbx
hacker is to offer a way to change the locations where the shell
completions are installed, which is necessary and beneficial for other
use-cases.
Z shell, unlike Bash's bash-completion.pc and fish's fish.pc, doesn't
offer an API to detect the location for the shell completions. This
means that Debian and Fedora use different locations [1, 2]. Namely,
/usr/share/zsh/vendor-completions and /usr/share/zsh/site-functions.
An option to specify the locations for the shell completions can
optimize the build, if there's an alternate API for the location that
doesn't involve using bash-completion.pc and fish.pc as build
dependencies. eg., Fedora provides the _tmpfilesdir RPM macro to
specify the location for vendor-supplied tmpfiles.d(5) files, which
makes it possible to avoid having systemd.pc as a build dependency [3].
Fallout from bafbbe81c9220cb3749a19a244e45a61477553a6
[1] Debian zsh commit bf0a44a8744469b5
https://salsa.debian.org/debian/zsh/-/commit/bf0a44a8744469b5
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620452
[2] https://src.fedoraproject.org/rpms/zsh/blob/f37/f/zsh.spec
[3] Fedora toolbox commit 9bebde5bb60f36e3
https://src.fedoraproject.org/rpms/toolbox/c/9bebde5bb60f36e3
https://github.com/containers/toolbox/pull/1123
https://github.com/containers/toolbox/pull/840
2022-09-09 11:25:52 +00:00
|
|
|
bashcompletionsdir = get_option('bash_completions_dir')
|
|
|
|
|
if bashcompletionsdir == ''
|
|
|
|
|
bash_completion_dep = dependency('bash-completion', required: false)
|
|
|
|
|
if bash_completion_dep.found()
|
|
|
|
|
bashcompletionsdir = bash_completion_dep.get_variable(pkgconfig: 'completionsdir')
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
fishcompletionsdir = get_option('fish_completions_dir')
|
|
|
|
|
if fishcompletionsdir == ''
|
|
|
|
|
fish_completion_dep = dependency('fish', required: false)
|
|
|
|
|
if fish_completion_dep.found()
|
|
|
|
|
fishcompletionsdir = fish_completion_dep.get_variable(pkgconfig: 'completionsdir')
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
zshcompletionsdir = get_option('zsh_completions_dir')
|
|
|
|
|
if zshcompletionsdir == ''
|
|
|
|
|
zshcompletionsdir = get_option('datadir') / 'zsh' / 'site-functions'
|
|
|
|
|
endif
|
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-09-09 13:30:28 +00:00
|
|
|
toolbox_sh = files('toolbox')
|
2022-08-29 19:59:08 +00:00
|
|
|
|
2022-10-24 11:27:24 +00:00
|
|
|
if codespell.found()
|
|
|
|
|
test(
|
|
|
|
|
'codespell',
|
|
|
|
|
codespell,
|
|
|
|
|
args: [
|
|
|
|
|
'--check-filenames',
|
|
|
|
|
'--check-hidden',
|
|
|
|
|
'--context', '3',
|
|
|
|
|
'--exclude-file', meson.project_source_root() / '.codespellexcludefile',
|
|
|
|
|
'--skip', meson.project_build_root(),
|
|
|
|
|
'--skip', meson.project_source_root() / '.git',
|
|
|
|
|
'--skip', meson.project_source_root() / 'test/system/libs/bats-assert',
|
|
|
|
|
'--skip', meson.project_source_root() / 'test/system/libs/bats-support',
|
|
|
|
|
meson.project_source_root(),
|
|
|
|
|
],
|
|
|
|
|
)
|
|
|
|
|
endif
|
|
|
|
|
|
2022-08-29 19:59:08 +00:00
|
|
|
if shellcheck.found()
|
2022-09-09 13:38:31 +00:00
|
|
|
test('shellcheck toolbox (deprecated)', shellcheck, args: [toolbox_sh])
|
2022-08-29 19:59:08 +00:00
|
|
|
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',
|
2022-10-21 14:50:31 +00:00
|
|
|
install_dir: get_option('datadir') / meson.project_name(),
|
2021-07-09 12:05:26 +00:00
|
|
|
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')
|
build: Enable changing the completion paths & drop install_completions
The bash-completion and fish dependencies were already optional - the
shell completions for Bash and fish won't be generated and installed if
they are absent; and there's no dependency required for Z shell. So the
install_completions build option wasn't reducing the dependency burden.
The build option was a way to disable the generation and installation of
the shell completions, regardless of whether the necessary dependencies
are present or not. The only use-case for this is when installing to a
non-system-wide prefix while hacking on Toolbox as a non-root user,
because the locations for the completions advertised by the shells' APIs
might not be accessible. Being able to disable the completions prevents
the installation from failing.
A different way of ensuring a smooth developer experience for a Toolbx
hacker is to offer a way to change the locations where the shell
completions are installed, which is necessary and beneficial for other
use-cases.
Z shell, unlike Bash's bash-completion.pc and fish's fish.pc, doesn't
offer an API to detect the location for the shell completions. This
means that Debian and Fedora use different locations [1, 2]. Namely,
/usr/share/zsh/vendor-completions and /usr/share/zsh/site-functions.
An option to specify the locations for the shell completions can
optimize the build, if there's an alternate API for the location that
doesn't involve using bash-completion.pc and fish.pc as build
dependencies. eg., Fedora provides the _tmpfilesdir RPM macro to
specify the location for vendor-supplied tmpfiles.d(5) files, which
makes it possible to avoid having systemd.pc as a build dependency [3].
Fallout from bafbbe81c9220cb3749a19a244e45a61477553a6
[1] Debian zsh commit bf0a44a8744469b5
https://salsa.debian.org/debian/zsh/-/commit/bf0a44a8744469b5
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620452
[2] https://src.fedoraproject.org/rpms/zsh/blob/f37/f/zsh.spec
[3] Fedora toolbox commit 9bebde5bb60f36e3
https://src.fedoraproject.org/rpms/toolbox/c/9bebde5bb60f36e3
https://github.com/containers/toolbox/pull/1123
https://github.com/containers/toolbox/pull/840
2022-09-09 11:25:52 +00:00
|
|
|
subdir('completion')
|
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')
|