bryson/pacman
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
pacman/meson.build

508 lines
16 KiB
Meson
Raw Permalink Normal View History

Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
project('pacman',
'c',
Update meson versions for release Signed-off-by: Allan McRae <allan@archlinux.org>
2024-07-07 20:14:35 +10:00
version : '7.0.0',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
license : 'GPLv2+',
default_options : [
'c_std=gnu99',
'prefix=/usr',
'sysconfdir=/etc',
'localstatedir=/var',
],
meson: use the custom meson provided intl dependency Let meson deal with the system differences instead of handling it manually. The custom dependency was added in meson 0.59, then gained static support with 0.60, and static support for cygwin with 0.61, which is why the meson requirement is bumped to 0.61. Debian bullseye ships meson 0.56, so switch to bookworm which has 1.0.1
2024-04-28 14:29:44 +02:00
meson_version : '>= 0.61')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
Update meson versions for release Signed-off-by: Allan McRae <allan@archlinux.org>
2024-07-07 20:14:35 +10:00
libalpm_version = '15.0.0'
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
cc = meson.get_compiler('c')
# commandline options
PREFIX = get_option('prefix')
DATAROOTDIR = join_paths(PREFIX, get_option('datarootdir'))
SYSCONFDIR = join_paths(PREFIX, get_option('sysconfdir'))
LOCALSTATEDIR = join_paths(PREFIX, get_option('localstatedir'))
LOCALEDIR = join_paths(PREFIX, get_option('localedir'))
ROOTDIR = get_option('root-dir')
BINDIR = join_paths(PREFIX, get_option('bindir'))
MANDIR = join_paths(PREFIX, get_option('mandir'))
BUILDSCRIPT = get_option('buildscript')
LIBMAKEPKGDIR = join_paths(PREFIX, DATAROOTDIR, 'makepkg')
PKGDATADIR = join_paths(PREFIX, DATAROOTDIR, meson.project_name())
Add --keyringdir meson option to configure the keyring directory On Debian, keyrings are stored in /usr/share/keyrings. To support this, let's add a new --keyringdir option that allows configuring the directory under datarootdir where the keyrings should be imported from. We default to 'pacman/keyrings' for backwards compatibility.
2022-07-27 17:10:33 +02:00
KEYRINGDIR = join_paths(PREFIX, DATAROOTDIR, get_option('keyringdir'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
PYTHON = import('python').find_installation('python3')
LDCONFIG = get_option('ldconfig')
meson: do not use meson.source_root() and meson.build_root() Using meson.source_root() and meson.build_root() are deprectated in meson-0.56. Using current_source_dir() or current_build_dir() (which have been available in all Meson versions) would require manually adding "../" in some places. Instead, use project_source_root() and project_build_root() and require meson-0.56. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 16:06:39 +10:00
MESON_MAKE_SYMLINK = join_paths(meson.project_source_root(), 'build-aux/meson-make-symlink.sh')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
BASH = find_program('bash4', 'bash')
if BASH.found()
Silence meson run_command warning Upsteam is warning about future change in the run_command check argument. Ref: https://github.com/mesonbuild/meson/issues/9300 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 14:51:00 +10:00
bash_version = run_command(BASH, '-c', 'IFS=.; echo "${BASH_VERSINFO[*]:0:3}"', check: true).stdout()
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
have_bash = bash_version.version_compare('>= 4.4.0')
endif
if not have_bash
error('bash >= 4.4.0 is required for pacman scripts.')
endif
bashcompletion = dependency('bash-completion', required : false)
if bashcompletion.found()
meson: replace deprecated get_pkgconfig_variable() Apparently that function was deprecated in 0.56, so use the generic getter introduced in 0.51 instead. This squashes a warning. Signed-off-by: Joe Baldino <pedanticdm@gmx.us> Signed-off-by: Allan McRae <allan@archlinux.org>
2022-07-28 05:36:11 +00:00
BASHCOMPDIR = bashcompletion.get_variable(pkgconfig: 'completionsdir')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
else
BASHCOMPDIR = join_paths(DATAROOTDIR, 'bash-completion/completions')
endif
if get_option('use-git-version')
PACKAGE_VERSION = run_command(
find_program('git'),
'describe',
'--abbrev=4',
Silence meson run_command warning Upsteam is warning about future change in the run_command check argument. Ref: https://github.com/mesonbuild/meson/issues/9300 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 14:51:00 +10:00
'--dirty',
check: true).stdout().strip().strip('v')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
else
PACKAGE_VERSION = meson.project_version()
endif
conf = configuration_data()
conf.set('_GNU_SOURCE', true)
conf.set_quoted('PACKAGE', meson.project_name())
conf.set_quoted('PACKAGE_VERSION', PACKAGE_VERSION)
conf.set_quoted('LOCALEDIR', LOCALEDIR)
conf.set_quoted('SCRIPTLET_SHELL', get_option('scriptlet-shell'))
conf.set_quoted('LDCONFIG', LDCONFIG)
meson: fix incorrect libalpm version LIB_VERSION is supposed to be something like 11.0.1, not simply reiterate the project version. As a result, we ended up with this: $ pacman -V [...] Pacman v5.1.0 - libalpm v5.1.0 [...] Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-09-18 23:46:58 -04:00
conf.set_quoted('LIB_VERSION', libalpm_version)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
conf.set_quoted('SYSHOOKDIR', join_paths(DATAROOTDIR, 'libalpm/hooks/'))
conf.set_quoted('CONFFILE', join_paths(SYSCONFDIR, 'pacman.conf'))
meson: add trailing slashes to directory components in configuration defines This matches what we currently do in the autotools build configuration, and ensures that the default pacman-conf definitions for unspecified values consistently end with the trailing directory slashes. This has ramifications for thirdparty tools that up to now, have relied on this slash being there. Those tools should be fixed to prevent breaking when custom locations are set, but this is no reason not to fix it on our end as well. An extra trailng slash should never cause harm. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-12-10 23:47:58 -05:00
conf.set_quoted('DBPATH', join_paths(LOCALSTATEDIR, 'lib/pacman/'))
conf.set_quoted('GPGDIR', join_paths(SYSCONFDIR, 'pacman.d/gnupg/'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
conf.set_quoted('LOGFILE', join_paths(LOCALSTATEDIR, 'log/pacman.log'))
meson: add trailing slashes to directory components in configuration defines This matches what we currently do in the autotools build configuration, and ensures that the default pacman-conf definitions for unspecified values consistently end with the trailing directory slashes. This has ramifications for thirdparty tools that up to now, have relied on this slash being there. Those tools should be fixed to prevent breaking when custom locations are set, but this is no reason not to fix it on our end as well. An extra trailng slash should never cause harm. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-12-10 23:47:58 -05:00
conf.set_quoted('CACHEDIR', join_paths(LOCALSTATEDIR, 'cache/pacman/pkg/'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
conf.set_quoted('HOOKDIR', join_paths(SYSCONFDIR, 'pacman.d/hooks/'))
conf.set_quoted('ROOTDIR', ROOTDIR)
build: add libintl dependency to meson and the .pc file In order to use gettext on systems where it is not part of libc, the correct linker flags are needed in libalpm.pc (for static compilation). This has never been the case. The new meson build system currently only checks for ngettext in libc, but does not fall back to searching for the existence of -lintl; add it to the libalpm dependencies. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2020-05-18 15:18:12 -04:00
libintl = dependency('', required: false)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
if get_option('i18n')
meson: use the custom meson provided intl dependency Let meson deal with the system differences instead of handling it manually. The custom dependency was added in meson 0.59, then gained static support with 0.60, and static support for cygwin with 0.61, which is why the meson requirement is bumped to 0.61. Debian bullseye ships meson 0.56, so switch to bookworm which has 1.0.1
2024-04-28 14:29:44 +02:00
libintl = dependency('intl', static: get_option('buildstatic'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
conf.set('ENABLE_NLS', 1)
endif
# dependencies
libarchive = dependency('libarchive',
version : '>=3.0.0',
static : get_option('buildstatic'))
makepkg: use bsdtar --no-read-sparse for archive creation if available bsdtar uses the "pax" TAR archive format by default, which has support for storing sparse file information in the archive. Unfortunately this is a source of unreproducibility because the sparse encoding is taken from the file system and different file systems handle sparse files differently: some file systems have no support for sparsely encoded files at all, and even file systems with sparse file support can report different file information for identical files due to differing implementations. As a real world example where this happens, consider the Arch Linux package "brotli-testdata 1.0.9-7", which contains a sparsely encoded all-zeros file "usr/share/brotli/testdata/zeros". Building this package on a btrfs file system yields a different package than building it on tmpfs or ext4 solely due to different sparse file information that gets recorded in the package tarball. To improve the reproducibility of archives containing sparsely encoded files, libarchive version 3.6.0 introduces a new --no-read-sparse option. This skips reading sparse file information from disk entirely and therefore stores files "expanded" in the archive, which is the only way to make them reliably reproducible across file systems. makepkg will use this option if libarchive is recent enough to support it, which is detected at build time. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-10 16:38:42 +01:00
if libarchive.version().version_compare('>=3.6.0')
bsdtar_no_read_sparse = '--no-read-sparse'
else
bsdtar_no_read_sparse = ''
endif
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
libcurl = dependency('libcurl',
libalpm: don't use curl's deprecated functions This bumps the minimun curl version from 7.32.0 to 7.55.0. Signed-off-by: Allan McRae <allan@archlinux.org>
2021-01-02 00:00:02 +00:00
version : '>=7.55.0',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
required : get_option('curl'),
static : get_option('buildstatic'))
conf.set('HAVE_LIBCURL', libcurl.found())
Bump required GPGME version to 1.12.0 GPGME_KEYLIST_MODE_LOCATE was introduced in 1.12.0 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-12-13 11:46:18 +10:00
needed_gpgme_version = '>=1.12.0'
build: check for gpgme with pkg-config before gpgme-config gpgme in git master now supports pkg-config and with the next release we can and should prefer its use. However, retain the legacy code that enables building with older versions of gpgme, as a fallback. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-03-07 23:10:38 -05:00
gpgme = dependency('gpgme',
meson: use dependency('gpgme') exclusively This works everywhere that gpgme >= 1.13.0 because it is a pkg-config dependency, and meson 0.51 adds a fallback config-tool dependency provider that detects older versions of gpgme seamlessly via gpgme-config. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-25 16:28:17 -04:00
version : needed_gpgme_version,
required : get_option('gpgme'),
static : get_option('buildstatic'),
not_found_message : 'gpgme @0@ is needed for GPG signature support'.format(needed_gpgme_version))
build: check for gpgme with pkg-config before gpgme-config gpgme in git master now supports pkg-config and with the next release we can and should prefer its use. However, retain the legacy code that enables building with older versions of gpgme, as a fallback. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-03-07 23:10:38 -05:00
conf.set('HAVE_LIBGPGME', gpgme.found())
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
want_crypto = get_option('crypto')
if want_crypto == 'openssl'
meson: use not_found_message when dependencies are not found The default state of `dependency()` is `required: true`, which means if a dependency is not found, meson immediately aborts and does not log our `error()` messages. meson 0.50 has builtin support for dependencies with custom error messages. The alternative would be to specify `required: false` everywhere, and only then to key off of `dep.found()`. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-25 16:28:16 -04:00
libcrypto = dependency('libcrypto', static : get_option('buildstatic'),
not_found_message : 'openssl support requested but not found')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
crypto_provider = libcrypto
conf.set10('HAVE_LIBSSL', true)
elif want_crypto == 'nettle'
meson: use not_found_message when dependencies are not found The default state of `dependency()` is `required: true`, which means if a dependency is not found, meson immediately aborts and does not log our `error()` messages. meson 0.50 has builtin support for dependencies with custom error messages. The alternative would be to specify `required: false` everywhere, and only then to key off of `dep.found()`. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-25 16:28:16 -04:00
libnettle = dependency('nettle', static : get_option('buildstatic'),
not_found_message : 'nettle support requested but not found')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
crypto_provider = libnettle
conf.set10('HAVE_LIBNETTLE', true)
else
error('unhandled crypto value @0@'.format(want_crypto))
endif
Restrict syscalls for the download process whenever possible Signed-off-by: Remi Gacogne <rgacogne@archlinux.org>
2024-04-03 17:05:18 +02:00
libseccomp = dependency('libseccomp',
static : get_option('buildstatic'),
required : false)
conf.set('HAVE_LIBSECCOMP', libseccomp.found())
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
foreach header : [
Restrict filesystem access to the download process whenever possible Signed-off-by: Remi Gacogne <rgacogne@archlinux.org>
2024-04-03 16:18:17 +02:00
'linux/landlock.h',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
'mntent.h',
'sys/mnttab.h',
'sys/mount.h',
'sys/param.h',
Ensure that the download process cannot get new privileges Signed-off-by: Remi Gacogne <rgacogne@archlinux.org>
2024-04-03 17:11:25 +02:00
'sys/prctl.h',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
'sys/statvfs.h',
'sys/types.h',
'sys/ucred.h',
'termios.h',
]
if cc.has_header(header)
conf.set('HAVE_' + header.underscorify().to_upper(), true)
endif
endforeach
foreach sym : [
'getmntent',
'getmntinfo',
'strndup',
'strnlen',
'strsep',
'swprintf',
'tcflush',
]
have = cc.has_function(sym, args : '-D_GNU_SOURCE')
meson.build: Fix detection of symbols This patch changes the behavior of meson to define configuration options *only* when the symbol checked is present. Currently, it defines all of them in config.h whether the symbol exists or not and the code that looks for it doesn't check the macro's value, but whether it's defined. Signed-off-by: Mark Weiman <mark.weiman@markzz.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-04-16 23:45:21 -04:00
if have
conf.set10('HAVE_' + sym.to_upper(), have)
endif
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
endforeach
foreach member : [
['struct stat', 'st_blksize', '''#include <sys/stat.h>'''],
['struct statvfs', 'f_flag', '''#include <sys/statvfs.h>'''],
['struct statfs', 'f_flags', '''#include <sys/param.h>
#include <sys/mount.h>'''],
]
have = cc.has_member(member[0], member[1], prefix : member[2])
conf.set('HAVE_' + '_'.join([member[0], member[1]]).underscorify().to_upper(), have)
endforeach
meson: port over checks for types used from sys/types.h These are defined by a POSIX standard, and we should assert that we have them, or define sane fallbacks (as per sys_types.h(0P)). Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-29 12:58:26 -04:00
foreach type : [
# type # program prefix # fallback
['mode_t', '''#include <sys/types.h>''', 'unsigned int'],
['uid_t', '''#include <sys/types.h>''', 'unsigned int'],
['off_t', '''#include <sys/types.h>''', 'signed int'],
['pid_t', '''#include <sys/types.h>''', 'signed int'],
['size_t', '''#include <sys/types.h>''', 'unsigned int'],
['ssize_t', '''#include <sys/types.h>''', 'signed int'],
['int64_t', '''#include <stdint.h>''', 'signed long int'],
]
if not cc.has_type(type[0], prefix: type[1])
conf.set(type[0], type[2])
endif
endforeach
Fix compile on some platforms Controlling the type of getmntinfo's param was decided by whether or not we had the statvfs type avaliable. But getmntinfo uses statfs regardless of this except on netbsd where it uses statvfs. Add a check to detect which type our version of the function uses.
2023-08-25 07:01:46 +02:00
if conf.has('HAVE_GETMNTINFO')
if cc.compiles('''
#include <sys/types.h>
#include <sys/statvfs.h>
void func() {
struct statvfs *buf;
getmntinfo(&buf, 0);
}
''')
conf.set('FSSTATSTYPE', 'struct statvfs')
else
conf.set('FSSTATSTYPE', 'struct statfs')
endif
elif conf.has('HAVE_STRUCT_STATVFS_F_FLAG')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
conf.set('FSSTATSTYPE', 'struct statvfs')
elif conf.has('HAVE_STRUCT_STATFS_F_FLAGS')
conf.set('FSSTATSTYPE', 'struct statfs')
endif
meson: use better check for debug builds meson 0.48 added the 'debug' and 'optimization' builtin options, which bidirectionally map to the buildtype, but in some cases where debug is enabled, the builtype may be custom. Checking the 'debug' option lets us detect every case currently detected, plus a few more, and does so in a shorter and more concise manner. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2020-05-05 00:41:09 -04:00
if get_option('debug')
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
extra_cflags = [
Add the -pedantic' compiler flag back to our debug builds This was lost in the transition from autotools to meson. No additional warnings are given with current gcc and clang. Signed-off-by: Allan McRae <allan@archlinux.org>
2023-02-09 11:48:20 +10:00
'-pedantic',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
'-Wcast-align',
'-Wclobbered',
'-Wempty-body',
'-Wfloat-equal',
'-Wformat-nonliteral',
'-Wformat-security',
'-Wignored-qualifiers',
Add implicit fall through warning Requires modification to our comment about fall through to match compilers expectations. Works for GCC and Clang. Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-12 11:17:30 +10:00
'-Wimplicit-fallthrough',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
'-Winit-self',
'-Wlogical-op',
'-Wmissing-declarations',
'-Wmissing-field-initializers',
'-Wmissing-parameter-type',
'-Wmissing-prototypes',
'-Wold-style-declaration',
'-Woverride-init',
'-Wpointer-arith',
'-Wredundant-decls',
'-Wshadow',
'-Wsign-compare',
'-Wstrict-aliasing',
'-Wstrict-overflow=5',
'-Wstrict-prototypes',
'-Wtype-limits',
'-Wuninitialized',
'-Wunused-but-set-parameter',
'-Wunused-parameter',
Add -Wunused_result to debug build compiler flags Signed-off-by: Allan McRae <allan@archlinux.org>
2024-01-25 23:58:11 +10:00
'-Wunused-result',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
'-Wwrite-strings',
]
add_project_arguments(cc.get_supported_arguments(extra_cflags), language : 'c')
conf.set('PACMAN_DEBUG', 1)
endif
config_h = configure_file(
output : 'config.h',
configuration : conf)
add_project_arguments('-include', 'config.h', language : 'c')
Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-08-11 23:46:25 -04:00
filecmd = 'file'
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
inodecmd = 'stat -c \'%i %n\''
strip_binaries = '--strip-all'
strip_shared = '--strip-unneeded'
strip_static = '--strip-debug'
Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-08-11 23:46:25 -04:00
file_seccomp = get_option('file-seccomp')
# meson-git has find_program('file', required: false, version: '>=5.38')
Silence meson run_command warning Upsteam is warning about future change in the run_command check argument. Ref: https://github.com/mesonbuild/meson/issues/9300 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 14:51:00 +10:00
filever = run_command('sh', '-c', 'file --version | sed -n "s/^file-\(.*\)/\\1/p"', check: true).stdout()
Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-08-11 23:46:25 -04:00
if file_seccomp.enabled() or ( file_seccomp.auto() and filever.version_compare('>= 5.38') )
filecmd = 'file -S'
endif
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
os = host_machine.system()
if os.startswith('darwin')
meson: fix inodecmd for darwin/bsd The BSD stat command uses %N, not %n, and was incorrectly ported to meson. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-27 02:11:28 -04:00
inodecmd = '/usr/bin/stat -f \'%i %N\''
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
strip_binaries = ''
strip_shared = '-s'
strip_static = '-s'
elif os.contains('bsd') or os == 'dragonfly'
meson: fix inodecmd for darwin/bsd The BSD stat command uses %N, not %n, and was incorrectly ported to meson. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-27 02:11:28 -04:00
inodecmd = 'stat -f \'%i %N\''
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
endif
Silence meson run_command warning Upsteam is warning about future change in the run_command check argument. Ref: https://github.com/mesonbuild/meson/issues/9300 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 14:51:00 +10:00
chost = run_command(cc, '-dumpmachine', check: true).stdout().strip()
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
carch = chost.split('-')[0]
# annoyingly, we have to maintain two sets of configuration_data which is
# largely identical, but which distinguishes between quoting needs.
substs = configuration_data()
substs.set('CARCH', carch)
substs.set('CHOST', chost)
substs.set('PKGEXT', get_option('pkg-ext'))
substs.set('SRCEXT', get_option('src-ext'))
substs.set('ROOTDIR', ROOTDIR)
substs.set('LOCALEDIR', LOCALEDIR)
substs.set('sysconfdir', SYSCONFDIR)
substs.set('localstatedir', LOCALSTATEDIR)
substs.set('PKGDATADIR', PKGDATADIR)
Add --keyringdir meson option to configure the keyring directory On Debian, keyrings are stored in /usr/share/keyrings. To support this, let's add a new --keyringdir option that allows configuring the directory under datarootdir where the keyrings should be imported from. We default to 'pacman/keyrings' for backwards compatibility.
2022-07-27 17:10:33 +02:00
substs.set('KEYRINGDIR', KEYRINGDIR)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
substs.set('PREFIX', PREFIX)
meson.build: change ExternalProgram.path to full_path Removes "Future-deprecated features used", but reuires meson-0.55 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 15:51:32 +10:00
substs.set('BASH', BASH.full_path())
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
substs.set('PACKAGE_VERSION', PACKAGE_VERSION)
substs.set('PACKAGE_NAME', meson.project_name())
substs.set('BUILDSCRIPT', BUILDSCRIPT)
substs.set('TEMPLATE_DIR', get_option('makepkg-template-dir'))
substs.set('DEBUGSUFFIX', get_option('debug-suffix'))
substs.set('INODECMD', inodecmd)
Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-08-11 23:46:25 -04:00
substs.set('FILECMD', filecmd)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
substs.set('LIBMAKEPKGDIR', LIBMAKEPKGDIR)
substs.set('STRIP_BINARIES', strip_binaries)
substs.set('STRIP_SHARED', strip_shared)
substs.set('STRIP_STATIC', strip_static)
makepkg: use bsdtar --no-read-sparse for archive creation if available bsdtar uses the "pax" TAR archive format by default, which has support for storing sparse file information in the archive. Unfortunately this is a source of unreproducibility because the sparse encoding is taken from the file system and different file systems handle sparse files differently: some file systems have no support for sparsely encoded files at all, and even file systems with sparse file support can report different file information for identical files due to differing implementations. As a real world example where this happens, consider the Arch Linux package "brotli-testdata 1.0.9-7", which contains a sparsely encoded all-zeros file "usr/share/brotli/testdata/zeros". Building this package on a btrfs file system yields a different package than building it on tmpfs or ext4 solely due to different sparse file information that gets recorded in the package tarball. To improve the reproducibility of archives containing sparsely encoded files, libarchive version 3.6.0 introduces a new --no-read-sparse option. This skips reading sparse file information from disk entirely and therefore stores files "expanded" in the archive, which is the only way to make them reliably reproducible across file systems. makepkg will use this option if libarchive is recent enough to support it, which is detected at build time. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-10 16:38:42 +01:00
substs.set('BSDTAR_NO_READ_SPARSE', bsdtar_no_read_sparse)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
subdir('lib/libalpm')
subdir('src/common')
subdir('src/pacman')
subdir('src/util')
subdir('scripts')
# Internationalization
if get_option('i18n')
i18n = import('i18n')
subdir('lib/libalpm/po')
subdir('src/pacman/po')
subdir('scripts/po')
endif
want_doc = get_option('doc')
ASCIIDOC = find_program('asciidoc', required : want_doc)
A2X = find_program('a2x', required : want_doc)
build_doc = A2X.found() and not want_doc.disabled()
if build_doc
subdir('doc')
endif
includes = include_directories('src/common', 'lib/libalpm')
libcommon = static_library(
'common',
libcommon_sources,
include_directories : includes,
meson: use hidden symbol visiblity by default All the required public API is annotated with SYMEXPORT, so we can just add the meson notation, to hide all the symbols by default. Thus we no longer spill all the internal API into the global namespace. This is effectively a regression from the autotools build, which used hidden and internal for DARWIN and others respectively. The use of hidden is considered sufficient, considering: - internal was introduced with commit 920b0d20 ("Update usage of gcc __attribute__ flags"), referencing the GCC manual and potential optimisations, although - the details about the optimisations or respective benefits are close to non-existent, - the code/data size of the binaries is identical across hidden and internal. While the latter produces slightly larger overall binaries. - Internal is not widely supported - missing on Darwin, the CMake build system lacks a wrapper (unlike for hidden) - Internal is not widely used in projects. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-01-05 00:48:12 +00:00
gnu_symbol_visibility : 'hidden',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
install : false)
Restrict syscalls for the download process whenever possible Signed-off-by: Remi Gacogne <rgacogne@archlinux.org>
2024-04-03 17:05:18 +02:00
alpm_deps = [crypto_provider, libarchive, libcurl, libintl, libseccomp, gpgme]
meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-02 03:20:13 -04:00
build: link vercmp with a static copy of libalpm This has historically been the case in autotools since we want vercmp to not break mid-transaction in an install script. For convenience, we create libalpm.a and use this to optionally generate libalpm.so (when not configured with -Dbuildstatic=true) as well as to link any binary which explicitly wishes to be built statically "with libalpm", but does not care where a function is defined. meson then treats this correctly: it builds the object file only once for both libraries, and the compiler strips out unused functionality from the final static binary. Currently the only binary which requires this is vercmp. Fixes FS#61719 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-11 11:19:26 -05:00
libalpm_a = static_library(
meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-02 03:20:13 -04:00
'alpm_objlib',
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
libalpm_sources,
meson: fix libcommon being publicly exposed as a static link dependency libcommon isn't even installed, so that means libalpm.a (if installed) is fatally broken as it misses objects. The problem is that meson doesn't handle this case correctly: https://github.com/mesonbuild/meson/issues/3934 https://github.com/mesonbuild/meson/issues/3937 https://github.com/mesonbuild/meson/pull/3939 Work around this by manually extracting libcommon's .o files into the list of objects used to create libalpm. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-09-18 23:44:57 -04:00
# https://github.com/mesonbuild/meson/issues/3937
Silence meson warning about extract_all_objects Upstream is changing the default from false to true. This makes no difference to us, so just set as the future default. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 15:07:57 +10:00
objects : libcommon.extract_all_objects(recursive: true),
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
include_directories : includes,
meson: use hidden symbol visiblity by default All the required public API is annotated with SYMEXPORT, so we can just add the meson notation, to hide all the symbols by default. Thus we no longer spill all the internal API into the global namespace. This is effectively a regression from the autotools build, which used hidden and internal for DARWIN and others respectively. The use of hidden is considered sufficient, considering: - internal was introduced with commit 920b0d20 ("Update usage of gcc __attribute__ flags"), referencing the GCC manual and potential optimisations, although - the details about the optimisations or respective benefits are close to non-existent, - the code/data size of the binaries is identical across hidden and internal. While the latter produces slightly larger overall binaries. - Internal is not widely supported - missing on Darwin, the CMake build system lacks a wrapper (unlike for hidden) - Internal is not widely used in projects. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-01-05 00:48:12 +00:00
gnu_symbol_visibility : 'hidden',
meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-02 03:20:13 -04:00
dependencies : alpm_deps)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-02 03:20:13 -04:00
libalpm = library(
'alpm',
version : libalpm_version,
objects: libalpm_a.extract_all_objects(recursive: true),
meson: make -uninstalled.pc correct This pkg-config file is automatically created in the meson-uninstalled/ directory of the build tree, and points to the built artifacts there. If this directory is added to PKG_CONFIG_PATH, it will be preferred over an installed copy. Making this work properly means it becomes trivially possible to build a private copy of libalpm, and then compile other projects using it rather than the system copy. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-04-18 23:25:13 -04:00
include_directories : includes,
meson: work around broken pkg-config file with private requires In addition to the general issue of staticlibs linkage, linking a static lib to a library() does not seem to generate the needed Libs.private. Rework how we handle this entirely. Instead of relying on convenience libraries, we will *sigh* go extract a boatload of .o files again, then relink those to the installable libalpm, while mentioning our dependencies again. We still have our guaranteed static library for linking arbitrary programs with (e.g. vercmp), and we still only generate one identical copy of the .o files, but now we potentially `ar` it up twice, which isn't so bad. And linking still works, and pkg-config files also still work. One alternative would be to explicitly list our dependencies to pkgconfig.generate with requires_private, but since gpgme might be an elevated config-tool dependency, this can fail with: meson.build:341:10: ERROR: requires argument not a string, library with pkgconfig-generated file or pkgconfig-dependency object, got <GpgmeDependency gpgme: True> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-10-02 03:20:13 -04:00
dependencies : alpm_deps,
install : true)
build: link vercmp with a static copy of libalpm This has historically been the case in autotools since we want vercmp to not break mid-transaction in an install script. For convenience, we create libalpm.a and use this to optionally generate libalpm.so (when not configured with -Dbuildstatic=true) as well as to link any binary which explicitly wishes to be built statically "with libalpm", but does not care where a function is defined. meson then treats this correctly: it builds the object file only once for both libraries, and the compiler strips out unused functionality from the final static binary. Currently the only binary which requires this is vercmp. Fixes FS#61719 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-11 11:19:26 -05:00
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
install_headers(
'lib/libalpm/alpm.h',
'lib/libalpm/alpm_list.h')
pkgconfig = import('pkgconfig')
pkgconfig.generate(
libalpm,
name : 'libalpm',
description : 'Arch Linux package management library',
version : libalpm_version,
meson.build: add _FILE_OFFSET_BITS to pkgconfig Meson automatically sets _FILE_OFFSET_BITS but that value was not getting carried through to the libalpm pkgconfig file, breaking downstream projects that relied on it. Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com>
2023-11-25 12:35:54 -08:00
url : 'http://archlinux.org/pacman/',
extra_cflags: [ '-D_FILE_OFFSET_BITS=64' ],
)
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
pacman_bin = executable(
'pacman',
pacman_sources,
include_directories : includes,
link_with : [libalpm, libcommon],
dependencies : [libarchive],
install : true,
)
executable(
'pacman-conf',
pacman_conf_sources,
include_directories : includes,
meson: pacman-conf add missing libcommon link Currently, we are erroneously exporting all the symbols via the libalpm.so. As such, the libcommon dependency is resolved. The libalpm.so exports are about to be resolved shortly, yet that exposed that pacman-conf is missing a link against libcommon. Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-01-05 00:48:11 +00:00
link_with : [libalpm, libcommon],
meson: fix build of executables with nonstandard libarchive path The libarchive header is used in alpm.h, and several binaries include this header. This is noticeably a problem when using e.g. the musl-gcc compiler which does not include /usr/include by default, and thus the build system reports: ...../lib/libalpm/alpm.h:35:10: fatal error: archive.h: No such file or directory More commonly, this will result in compiling against potentially the wrong headers, if the libarchive installation picked up by pkg-config is different from the one with headers in /usr/include, and /usr/include is in the -isystem path. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-04-14 20:56:17 -04:00
dependencies : [libarchive],
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
install : true,
)
executable(
'testpkg',
testpkg_sources,
include_directories : includes,
link_with : [libalpm],
meson: fix build of executables with nonstandard libarchive path The libarchive header is used in alpm.h, and several binaries include this header. This is noticeably a problem when using e.g. the musl-gcc compiler which does not include /usr/include by default, and thus the build system reports: ...../lib/libalpm/alpm.h:35:10: fatal error: archive.h: No such file or directory More commonly, this will result in compiling against potentially the wrong headers, if the libarchive installation picked up by pkg-config is different from the one with headers in /usr/include, and /usr/include is in the -isystem path. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-04-14 20:56:17 -04:00
dependencies : [libarchive],
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
install : true,
)
executable(
'vercmp',
vercmp_sources,
include_directories : includes,
build: link vercmp with a static copy of libalpm This has historically been the case in autotools since we want vercmp to not break mid-transaction in an install script. For convenience, we create libalpm.a and use this to optionally generate libalpm.so (when not configured with -Dbuildstatic=true) as well as to link any binary which explicitly wishes to be built statically "with libalpm", but does not care where a function is defined. meson then treats this correctly: it builds the object file only once for both libraries, and the compiler strips out unused functionality from the final static binary. Currently the only binary which requires this is vercmp. Fixes FS#61719 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-11 11:19:26 -05:00
link_with : [libalpm_a],
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
install : true,
)
meson: make non-symlink scripts install for real, and use a better wrapper We now generate the scripts using their real name, install them using meson's builtin facility instead of an install_script, and generate the wrapper scripts in the root of the build directory, instead of a subdirectory. This gets us closer to resolving FS#64394. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-11-12 01:34:30 -05:00
foreach wrapper : script_wrappers
cdata = configuration_data()
meson.build: change ExternalProgram.path to full_path Removes "Future-deprecated features used", but reuires meson-0.55 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 15:51:32 +10:00
cdata.set_quoted('BASH', BASH.full_path())
meson: make non-symlink scripts install for real, and use a better wrapper We now generate the scripts using their real name, install them using meson's builtin facility instead of an install_script, and generate the wrapper scripts in the root of the build directory, instead of a subdirectory. This gets us closer to resolving FS#64394. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-11-12 01:34:30 -05:00
cdata.set_quoted('BUILDDIR', wrapper[2])
cdata.set_quoted('REAL_PROGPATH', wrapper[1].full_path())
# Create a wrapper script that bootstraps the real script within the build
# directory. Use configure_file instead of a custom_target to ensure that
# permissions on the input script wrapper are preserved.
configure_file(
meson: do not use meson.source_root() and meson.build_root() Using meson.source_root() and meson.build_root() are deprectated in meson-0.56. Using current_source_dir() or current_build_dir() (which have been available in all Meson versions) would require manually adding "../" in some places. Instead, use project_source_root() and project_build_root() and require meson-0.56. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 16:06:39 +10:00
input : join_paths(meson.project_source_root(), 'build-aux', 'script-wrapper.sh.in'),
meson: make non-symlink scripts install for real, and use a better wrapper We now generate the scripts using their real name, install them using meson's builtin facility instead of an install_script, and generate the wrapper scripts in the root of the build directory, instead of a subdirectory. This gets us closer to resolving FS#64394. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-11-12 01:34:30 -05:00
output : wrapper[0],
configuration : cdata)
endforeach
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
configure_file(
input : 'etc/makepkg.conf.in',
output : 'makepkg.conf',
configuration : substs,
install_dir : SYSCONFDIR)
makepkg: Add support for Fortran build flags Signed-off-by: Allan McRae <allan@archlinux.org>
2024-02-24 20:10:23 +10:00
configure_file(
input : 'etc/makepkg.conf.d/fortran.conf.in',
output : 'fortran.conf',
configuration : substs,
install_dir : join_paths(SYSCONFDIR, 'makepkg.conf.d/'))
makepkg.conf: allow configuration additions via a subdirectory Move rust related buildflags to their own configuration file to provide an example of how other languages could be supported. Signed-off-by: Allan McRae <allan@archlinux.org>
2023-01-13 11:32:52 +10:00
configure_file(
input : 'etc/makepkg.conf.d/rust.conf.in',
output : 'rust.conf',
configuration : substs,
install_dir : join_paths(SYSCONFDIR, 'makepkg.conf.d/'))
libmakepkg: Use only /etc/makepkg.d/gitconfig Globally set `GIT_CONFIG_GLOBAL` and `GIT_CONFIG_SYSTEM` so that we're only loading `/etc/makepkg.d/gitconfig` (if it exists) and no other Git config files. Allow injecting another value via `MAKEPKG_GIT_CONFIG`. Fixes: https://gitlab.archlinux.org/pacman/pacman/-/issues/193
2025-03-19 21:14:51 +01:00
install_emptydir(join_paths(SYSCONFDIR, 'makepkg.d/'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
configure_file(
input : 'etc/pacman.conf.in',
output : 'pacman.conf',
configuration : substs,
install_dir : SYSCONFDIR)
install_data(
'proto/PKGBUILD-split.proto',
'proto/PKGBUILD-vcs.proto',
'proto/PKGBUILD.proto',
'proto/proto.install',
install_dir : join_paths(DATAROOTDIR, 'pacman'))
meson: install the directories needed for successful pacman operation This was neglected in the initial meson port. We need these directories to exist in order to bootstrap a new installation. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-12-10 01:15:19 -05:00
foreach path : [
join_paths(LOCALSTATEDIR, 'lib/pacman/'),
join_paths(LOCALSTATEDIR, 'cache/pacman/pkg/'),
join_paths(DATAROOTDIR, 'makepkg-template/'),
join_paths(DATAROOTDIR, 'libalpm/hooks/'),
]
meson.add_install_script('sh', '-c', 'mkdir -p "$DESTDIR/@0@"'.format(path))
endforeach
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
TEST_ENV = environment()
meson: do not use meson.source_root() and meson.build_root() Using meson.source_root() and meson.build_root() are deprectated in meson-0.56. Using current_source_dir() or current_build_dir() (which have been available in all Meson versions) would require manually adding "../" in some places. Instead, use project_source_root() and project_build_root() and require meson-0.56. Signed-off-by: Allan McRae <allan@archlinux.org>
2022-03-06 16:06:39 +10:00
TEST_ENV.set('PMTEST_SCRIPTLIB_DIR', join_paths(meson.project_source_root(), 'scripts/library/'))
TEST_ENV.set('PMTEST_LIBMAKEPKG_DIR', join_paths(meson.project_build_root(), 'scripts/libmakepkg/'))
TEST_ENV.set('PMTEST_UTIL_DIR', meson.project_build_root() + '/')
TEST_ENV.set('PMTEST_SCRIPT_DIR', join_paths(meson.project_build_root(), 'scripts/'))
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
subdir('test/pacman')
subdir('test/scripts')
subdir('test/util')
message('\n '.join([
'@0@ @1@'.format(meson.project_name(), meson.project_version()),
'Build information:',
' prefix : @0@'.format(PREFIX),
' sysconfdir : @0@'.format(SYSCONFDIR),
' conf file : @0@'.format(join_paths(SYSCONFDIR, 'pacman.conf')),
' localstatedir : @0@'.format(LOCALSTATEDIR),
' database dir : @0@'.format(join_paths(LOCALSTATEDIR, 'lib/pacman/')),
' cache dir : @0@'.format(join_paths(LOCALSTATEDIR, 'cache/pacman/pkg/')),
Add --keyringdir meson option to configure the keyring directory On Debian, keyrings are stored in /usr/share/keyrings. To support this, let's add a new --keyringdir option that allows configuring the directory under datarootdir where the keyrings should be imported from. We default to 'pacman/keyrings' for backwards compatibility.
2022-07-27 17:10:33 +02:00
' keyringdir : @0@'.format(KEYRINGDIR),
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
' compiler : @0@ @1@'.format(cc.get_id(), cc.version()),
'',
' Architecture : @0@'.format(carch),
' Host Type : @0@'.format(chost),
' File inode command : @0@'.format(inodecmd),
Support file with seccomp enabled Not all compression types can be detected in the seccomp sandbox, so we need to disable it. This requires either configuring makepkg to know the sandbox is available, or checking for file >= 5.38 in which the sandbox option is a no-op even when seccomp is disabled. - Requires autoconf-archive for autotools version compare macro. - meson version comparison could be made a lot simpler using meson-git. Fixes FS#58626 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-08-11 23:46:25 -04:00
' File seccomp command : @0@'.format(filecmd),
Add meson.build files to build with meson Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-07-07 10:29:48 -04:00
' libalpm version : @0@'.format(libalpm_version),
' pacman version : @0@'.format(PACKAGE_VERSION),
'',
'Directory and file information:',
' root working directory : @0@'.format(ROOTDIR),
' package extension : @0@'.format(get_option('pkg-ext')),
' source pkg extension : @0@'.format(get_option('src-ext')),
' build script name : @0@'.format(BUILDSCRIPT),
' template directory : @0@'.format(get_option('makepkg-template-dir')),
'',
'Compilation options:',
' i18n support : @0@'.format(get_option('i18n')),
' Build docs : @0@'.format(build_doc),
' debug build : @0@'.format(get_option('buildtype') == 'debug'),
' Use libcurl : @0@'.format(conf.get('HAVE_LIBCURL')),
' Use GPGME : @0@'.format(conf.get('HAVE_LIBGPGME')),
' Use OpenSSL : @0@'.format(conf.has('HAVE_LIBSSL') and
conf.get('HAVE_LIBSSL') == 1),
' Use nettle : @0@'.format(conf.has('HAVE_LIBNETTLE') and
conf.get('HAVE_LIBNETTLE') == 1),
'',
]))
Reference in a new issue Copy permalink