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

103 lines
3 KiB
Meson
Raw Normal View History

meson: separate out wrapped from non-wrapped scripts makepkg-template is a perl script and doesn't get wrapped by our shell wrapper. It (wrongly) reads from the host machine rather than the build root, but this is working as implemented.
2018-11-03 19:58:31 -04:00
wrapped_scripts = [
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
'makepkg.sh.in',
'pacman-db-upgrade.sh.in',
'pacman-key.sh.in',
'repo-add.sh.in'
]
meson: separate out wrapped from non-wrapped scripts makepkg-template is a perl script and doesn't get wrapped by our shell wrapper. It (wrongly) reads from the host machine rather than the build root, but this is working as implemented.
2018-11-03 19:58:31 -04:00
scripts = [
'makepkg-template.pl.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
SCRIPT_EDITOR = find_program(configure_file(
input : join_paths(meson.source_root(), 'build-aux/edit-script.sh.in'),
output : 'edit-script.sh',
configuration : substs))
m4_edit = generator(
M4,
arguments : ['-P', '-I', meson.current_source_dir(), '@INPUT@'],
output : '@PLAINNAME@',
capture : true)
foreach script : scripts
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
script_shortname = script.split('.')[0]
meson: separate out wrapped from non-wrapped scripts makepkg-template is a perl script and doesn't get wrapped by our shell wrapper. It (wrongly) reads from the host machine rather than the build root, but this is working as implemented.
2018-11-03 19:58:31 -04:00
custom_target(
script,
input : m4_edit.process(script),
command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@', '0755'],
output : script_shortname,
install : true,
install_dir : get_option('bindir'))
endforeach
foreach script : wrapped_scripts
script_shortname = script.split('.')[0]
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
# Build the script, but don't install it. We want to keep it as a "private"
# artifact that we reference from a wrapper script in order to bootstrap it
# the build directory.
internal_script = custom_target(
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
script,
input : m4_edit.process(script),
command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@', '0755'],
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
output : script,
build_by_default : true)
scripts/meson: ensure wrapper scripts are executable
2018-11-13 23:17:02 -05:00
cdata = configuration_data()
cdata.set_quoted('BASH', BASH.path())
cdata.set_quoted('BUILDDIR', meson.current_build_dir())
cdata.set_quoted('REAL_PROGPATH', internal_script.full_path())
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
# Create a wrapper script that bootstraps the real script within the build
scripts/meson: ensure wrapper scripts are executable
2018-11-13 23:17:02 -05:00
# directory. Use configure_file instead of a custom_target to ensure that
# permissions on the input script wrapper are preserved.
configure_file(
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
input : join_paths(meson.source_root(), 'build-aux', 'script-wrapper.sh.in'),
output : script_shortname,
scripts/meson: ensure wrapper scripts are executable
2018-11-13 23:17:02 -05:00
configuration : cdata)
meson: add a wrapper to bootstrap scripts from within build dir 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-10-28 02:42:53 -04:00
# Install the real script
meson.add_install_script(MESON_INSTALL_SCRIPT,
internal_script.full_path(),
join_paths(BINDIR, script_shortname))
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
endforeach
foreach symlink : ['repo-remove', 'repo-elephant']
meson.add_install_script(MESON_MAKE_SYMLINK,
'repo-add',
join_paths(BINDIR, symlink))
endforeach
subdir('libmakepkg')
libmakepkg: install pkg-config file Since makepkg exports a public library of functions, other projects may wish to use these functions. Highlights include parseopts or our messaging functions. Install a pkg-config file in order to let downstream users detect where they can source the libmakepkg functionality. This is useful e.g. to gracefully handle the case where a thirdparty project is configured and installed into a different datarootdir from pacman, but still wants to use the installed pacman's version of libmakepkg. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-05-07 21:55:03 -04:00
configure_file(
configuration : { 'libmakepkgdir': LIBMAKEPKGDIR, 'PACKAGE_VERSION': PACKAGE_VERSION },
input : 'libmakepkg.pc.in',
output : '@BASENAME@',
install_dir : join_paths(DATAROOTDIR, 'pkgconfig'))
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
custom_target(
'bash_completion',
command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@' ],
input : 'completion/bash_completion.in',
output : 'pacman',
install : true,
install_dir : BASHCOMPDIR)
foreach symlink : ['pacman-key', 'makepkg']
meson.add_install_script(MESON_MAKE_SYMLINK,
'pacman',
join_paths(BASHCOMPDIR, symlink))
endforeach
zsh_completion_dir = join_paths(DATAROOTDIR, 'zsh/site-functions')
custom_target(
'zsh_completion',
command : [ SCRIPT_EDITOR, '@INPUT@', '@OUTPUT@' ],
input : 'completion/zsh_completion.in',
output : '_pacman',
install : true,
install_dir : zsh_completion_dir)
Reference in a new issue Copy permalink