We should not need to hardcode the path to sed as we simply don't care.
We don't check what kind of sed we found, and we're using the same one
we initially found on the PATH, which is surely still on the PATH.
At one point we did care to find the system copy of sed and hardcode it
in makepkg, because we also passed non-portable -i options to it and
makepkg needed to continue working on macOS even if some incompatible
GNU sed got installed afterward, elsewhere on the PATH. But this was
never relevant to the in-tree buildsystem script running sed.
In commit 3a814ee6bc we removed even that,
so we don't need to look it up at all.
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>
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>
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>
Instead of assuming all scripts are .sh.in and leaving a comment to that
effect, just take the input file directly.
Signed-off-by: Allan McRae <allan@archlinux.org>
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.
