| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
pkgdelta was the last user, and it is gone now.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Since makepkg exports a public library of functions, other projects may
wish to use these functions. Highlights include parseopts or our
messaging functions.
Install a pkg-config file in order to let downstream users detect where
they can source the libmakepkg functionality. This is useful e.g. to
gracefully handle the case where a thirdparty project is configured and
installed into a different datarootdir from pacman, but still wants to
use the installed pacman's version of libmakepkg.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
Signed-off-by: Allan McRae <allan@archlinux.org>
|
|
|
|
This was only ever used by paccache, and paccache has since been moved
to pacman-contrib.
|
|
makepkg-template is a perl script and doesn't get wrapped by our shell
wrapper. It (wrongly) reads from the host machine rather than the build
root, but this is working as implemented.
|
|
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.
|