summaryrefslogtreecommitdiffstats
path: root/meson.build
AgeCommit message (Collapse)AuthorFilesLines
2019-10-07meson: work around broken pkg-config file with private requiresEli Schwartz1-12/+10
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-07meson: fix incorrect libalpm versionEli Schwartz1-1/+1
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-10-07meson: fix libcommon being publicly exposed as a static link dependencyEli Schwartz1-2/+2
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-10-07Support file with seccomp enabledEli Schwartz1-0/+10
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-05meson: port over checks for types used from sys/types.hDave Reisner1-0/+15
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-08-05meson: drop checks for things we don't useDave Reisner1-25/+0
This was ported over from the AC_CHECK_{FUNCS,HEADERS} lists in configure.ac, but I never actually checked if the resulting CPP defines are used. Turns out, lots of symbols, not a lot of define usage. Signed-off-by: Allan McRae <allan@archlinux.org>
2019-06-28meson: use dependency('gpgme') exclusivelyEli Schwartz1-28/+5
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-28meson: use not_found_message when dependencies are not foundEli Schwartz1-8/+4
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-28meson: bump the minimum supported version of meson to 0.51Eli Schwartz1-1/+1
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-05-08meson: fix build of executables with nonstandard libarchive pathEli Schwartz1-0/+2
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-03-19build: check for gpgme with pkg-config before gpgme-configEli Schwartz1-22/+27
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-19drop DU* config variablesSantiago Torres1-11/+0
Since DUFLAGS and DUPATH are not needed anymore remove them from the source Signed-off-by: Santiago Torres <santiago@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-03-19build: remove references to variable replacements from pacman-optimizeEli Schwartz1-10/+0
MODECMD and OWNERCMD are not used by pacman itself, so we don't need to check for and replace them now that pacman-optimize is removed. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-03-07Remove cleanupdeltaAllan McRae1-8/+0
Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-21meson: fix static/shared split againEli Schwartz1-2/+2
shared_library does not generate a sane pkg-config file because it assumes we don't want dependencies. Additionally, since we key off of buildstatic, when *not* using buildstatic but attempting to build libalpm on its own as static using -Ddefault_library=static, we are building and linking to a shared libalpm anyway. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-02-12build: link vercmp with a static copy of libalpmEli Schwartz1-3/+12
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-12Add implicit fall through warningAllan McRae1-0/+1
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>
2018-12-12meson: add trailing slashes to directory components in configuration definesEli Schwartz1-3/+3
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-12meson: install the directories needed for successful pacman operationEli Schwartz1-0/+9
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-10Enable additional debug flags/logging with debugoptimized buildsDave Reisner1-1/+1
This lets developers run a local build with optimizations but also the added debug logging that comes with PACMAN_DEBUG being defined. Signed-off-by: Allan McRae <allan@archlinux.org>
2018-11-02meson: add a wrapper to bootstrap scripts from within build dirDave Reisner1-0/+1
This doesn't do quite as good of a job of "hiding away" the real script as we did with autotools, but it satisfies the need for being able to run scripts which depend on libmakepkg with the local copy within the repo. We do, however, improve upon the autotools script by ensuring that the bash path used in configuring pacman is the interpreter used to run the underlying script.
2018-11-02Add meson.build files to build with mesonDave Reisner1-0/+487
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.
generated by cgit v1.2.3-24-g4f1b (git 2.32.0) at 2024-11-11 07:37:24 +0100