pacman/scripts/libmakepkg/util/meson.build

libmakepkg_module = 'util'

sources = [
  'compress.sh.in',
  'config.sh.in',
  'dirsize.sh.in',
  'error.sh.in',
  'message.sh.in',
  'option.sh.in',
  'parseopts.sh.in',
  'pkgbuild.sh.in',
  'schema.sh.in',
  'source.sh.in',
  'util.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
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 = 'util'`

			`sources = [`
			`'compress.sh.in',`
makepkg: move config loading into libmakepkg When scripting/automating around makepkg, it is sometimes desirable to know how makepkg will be configured to operate. One example is the archlinux devtools, which must forward select makepkg.conf variables into a build chroot (for example PACKAGER) or use those variables itself (for example {SRC,PKG,LOG}DEST). The configuration file can be in up to 3 places, and should be capable of being overridden via environment variables. It is sufficiently complex to represent distinct functionality, and sufficiently useful to merit easy accessibility in other scripts, therefore, let us move it into a publicly exposed utility library. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org> 2019-05-22 10:44:26 -04:00			`'config.sh.in',`
Comma fail 2019-10-30 14:24:47 +10:00			`'dirsize.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			`'error.sh.in',`
			`'message.sh.in',`
			`'option.sh.in',`
			`'parseopts.sh.in',`
			`'pkgbuild.sh.in',`
libmakepkg: centralise random arrays of pkgbuild variables Refactor many of the different arrays of pkgbuild variables into scripts/libmakepkg/util/schema.sh.in. Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org> 2019-01-30 18:07:20 +00:00			`'schema.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			`'source.sh.in',`
			`'util.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`