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

470 lines
15 KiB
Meson
Raw 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',
Release v6.0.2 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-10-03 12:52:04 +10:00
version : '6.0.2',
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: bump the minimum supported version of meson to 0.51 We haven't reached our first public release of the meson build backend yet, so we have lots of flexibility for this... and build dependencies are easier to upgrade than runtime dependencies anyway. Updating meson allows us to make use of a bunch of new features that rewquire the latest version of meson. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-25 16:28:15 -04:00
meson_version : '>= 0.51')
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
Release v6.0.2 Signed-off-by: Allan McRae <allan@archlinux.org>
2022-10-03 12:52:04 +10:00
libalpm_version = '13.0.2'
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())
PYTHON = import('python').find_installation('python3')
LDCONFIG = get_option('ldconfig')
MESON_MAKE_SYMLINK = join_paths(meson.source_root(), 'build-aux/meson-make-symlink.sh')
BASH = find_program('bash4', 'bash')
if BASH.found()
bash_version = run_command(BASH, '-c', 'IFS=.; echo "${BASH_VERSINFO[*]:0:3}"').stdout()
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()
BASHCOMPDIR = bashcompletion.get_pkgconfig_variable('completionsdir')
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',
'--dirty').stdout().strip().strip('v')
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')
if not cc.has_function('ngettext')
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 = cc.find_library('intl', required : false, static: get_option('buildstatic'))
if not libintl.found()
error('ngettext not found but NLS support requested')
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
endif
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> (cherry picked from commit f5f9e0f4ea30503657944b5c34690bd36069b07e)
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())
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
needed_gpgme_version = '>=1.3.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
foreach header : [
'mntent.h',
'sys/mnttab.h',
'sys/mount.h',
'sys/param.h',
'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
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 conf.has('HAVE_STRUCT_STATVFS_F_FLAG')
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 = [
'-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',
'-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')
filever = run_command('sh', '-c', 'file --version | sed -n "s/^file-\(.*\)/\\1/p"').stdout()
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
chost = run_command(cc, '-dumpmachine').stdout().strip()
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)
substs.set('PREFIX', PREFIX)
substs.set('BASH', BASH.path())
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> (cherry picked from commit f5f9e0f4ea30503657944b5c34690bd36069b07e)
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)
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
alpm_deps = [crypto_provider, libarchive, libcurl, libintl, 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
objects : libcommon.extract_all_objects(),
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,
Update urls to not use www. for archlinux.org www.archlinux.org now redirects to archlinux.org. Signed-off-by: Jelle van der Waa <jelle@vdwaa.nl> Signed-off-by: Allan McRae <allan@archlinux.org>
2021-04-07 21:43:27 +02:00
url : 'http://archlinux.org/pacman/')
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()
cdata.set_quoted('BASH', BASH.path())
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(
input : join_paths(meson.source_root(), 'build-aux', 'script-wrapper.sh.in'),
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)
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()
TEST_ENV.set('PMTEST_SCRIPTLIB_DIR', join_paths(meson.source_root(), 'scripts/library/'))
TEST_ENV.set('PMTEST_LIBMAKEPKG_DIR', join_paths(meson.build_root(), 'scripts/libmakepkg/'))
TEST_ENV.set('PMTEST_UTIL_DIR', meson.build_root() + '/')
TEST_ENV.set('PMTEST_SCRIPT_DIR', join_paths(meson.build_root(), 'scripts/'))
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/')),
' 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