1. 26 Jun, 2020 1 commit
  2. 01 Nov, 2019 1 commit
  3. 29 Oct, 2019 1 commit
  4. 21 Oct, 2019 1 commit
  5. 07 Oct, 2019 4 commits
  6. 05 Aug, 2019 2 commits
  7. 28 Jun, 2019 3 commits
  8. 08 May, 2019 1 commit
    • Eli Schwartz's avatar
      meson: fix build of executables with nonstandard libarchive path · 583f3122
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      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's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
  9. 19 Mar, 2019 3 commits
  10. 07 Mar, 2019 1 commit
  11. 21 Feb, 2019 1 commit
  12. 12 Feb, 2019 2 commits
    • Eli Schwartz's avatar
      build: link vercmp with a static copy of libalpm · 477a66cd
      Eli Schwartz authored and Allan McRae's avatar Allan McRae committed
      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's avatarEli Schwartz <eschwartz@archlinux.org>
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
    • Allan McRae's avatar
      Add implicit fall through warning · 86004227
      Allan McRae authored
      Requires modification to our comment about fall through to match compilers
      expectations.  Works for GCC and Clang.
      Signed-off-by: Allan McRae's avatarAllan McRae <allan@archlinux.org>
  13. 12 Dec, 2018 2 commits
  14. 10 Dec, 2018 1 commit
  15. 02 Nov, 2018 2 commits
    • Dave Reisner's avatar
      meson: add a wrapper to bootstrap scripts from within build dir · d230ec6f
      Dave Reisner authored
      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.
    • Dave Reisner's avatar
      Add meson.build files to build with meson · 51db8475
      Dave Reisner authored
      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.