bryson/pacman
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
pacman/scripts/libmakepkg/lint_config/meson.build

24 lines
518 B
Meson
Raw Normal View History

Add meson.build files to build with meson 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.
2018-07-07 10:29:48 -04:00
libmakepkg_module = 'lint_config'
sources = [
libmakepkg: add linting of BUILDENV and OPTIONS from makepkg.conf Currently the options array from a PKGBUILD is linted, but the global BUILDENV and OPTIONS are not. Fixes #233. Signed-off-by: Allan McRae <allan@archlinux.org>
2025-08-02 15:32:11 +10:00
'buildenv.sh.in',
libmakepkg: add lint_config to validate SRCEXT/PKGEXT These variables must begin with .src.tar / .pkg.tar respectively, so fail early if those expectations are not matched. This prevents makepkg from creating e.g. package files literally named "./pacman-5.1.3-1-x86_64" which are actually uncompressed tarballs. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-05-22 10:39:43 -04:00
'ext.sh.in',
lint_config: ensure NPROC is set to something usable We use NPROC for managing the number of parallel jobs to run, so it is essentially that this is a valid number. Add a lint pass, and move the setting of the default value to this location. Signed-off-by: Allan McRae <allan@archlinux.org>
2025-01-01 22:15:33 +10:00
'nproc.sh.in',
lint_config: move PACKAGER check into its own function The check for the format of the PACKAGER variable did not align with the rest of the function where it was located. Move to its own function. Signed-off-by: Allan McRae <allan@archlinux.org>
2025-01-01 22:20:03 +10:00
'packager.sh.in',
Add meson.build files to build with meson 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.
2018-07-07 10:29:48 -04:00
'paths.sh.in',
libmakepkg: add routine for linting $SOURCE_DATE_EPOCH This can only ever be an int, and the specification states that a malformed timestamp should be considered a fatal error. https://reproducible-builds.org/specs/source-date-epoch/ Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-10 00:58:41 -05:00
'source_date_epoch.sh.in',
Add meson.build files to build with meson 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.
2018-07-07 10:29:48 -04:00
'variable.sh.in',
]
foreach src : sources
output_dir = join_paths(get_option('datadir'), 'makepkg', libmakepkg_module)
custom_target(
libmakepkg_module + '_' + src.underscorify(),
command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@' ],
input : src,
output : '@BASENAME@',
install : true,
install_dir : output_dir)
endforeach
Reference in a new issue Copy permalink