| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
This bumps the minimun curl version from 7.32.0 to 7.55.0.
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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>
|
|
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>
|
|
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>
|
|
Now that library/ is fully gone, we don't need this anymore.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Reads PKGBUILD into an array and replaces the pkgver and pkgrel with
bash parameter substitution, then uses shell redirection to write to to
the file. Because shell redirection follows symlinks, this accomplishes
the same thing as the previous default of using the GNU-specific
--follow-symlinks sed flag.
Removes SEDPATH and SEDINPLACEFLAGS from the build systems as they are
not used elsewhere.
Signed-off-by: Ethan Sommer <e5ten.arch@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|