| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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.
|
