pacman - Archlinux32 fork of pacman

Age	Commit message (Collapse)	Author
2018-12-12	meson: add trailing slashes to directory components in configuration defines	Eli Schwartz
	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>
2018-12-12	meson: install the directories needed for successful pacman operation	Eli Schwartz
	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>
2018-12-10	Enable additional debug flags/logging with debugoptimized builds	Dave Reisner
	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>
2018-11-02	meson: add a wrapper to bootstrap scripts from within build dir	Dave Reisner
	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.
2018-11-02	Add meson.build files to build with meson	Dave Reisner
	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.