Arch Linux has been setting PYTHONHASHSEED=0 to create deterministic
.pyc files. After a thorough review by the Arch Security Team, setting
this variable was determined not to generated vulnerable .pyc files, as
when the loader loads the .pyc file and unmarshalls it, the internal
runtime will just populate the unordered data structures and use a new
runtime hash for them.
Signed-off-by: Allan McRae <allan@archlinux.org>
directories are created by install_dir within the subdir custom_target
installation targets.
Signed-off-by: Eli Schwartz <eschwartz@archlinux.org>
Signed-off-by: Allan McRae <allan@archlinux.org>
This opens the door for third parties to provide libmakepkg
extentions for the purpose of altering the build environment.
Signed-off-by: Que Quotion <quequotion@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
This opens the door for third parties who provide extensions to
libmakepkg to supply scripts that confirm the presence of their
dependant executables.
Signed-off-by: Que Quotion <quequotion@gmail.com>
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.
