Don't assume itstool, msgfmt et al. are just magically on the path.
Normally for commands being processed in build.ninja we'd look up the
program in order to run it. Offer the same guarantee for programs being
passed through an awkward script wrapper.
Don't just create a .PHONY target which runs a script that magically
generates files ninja doesn't know about. It results in untracked files,
and `meson install` has to run additional commands instead of copying
over files, and then cannot track them to uninstall them later.
I'm not even really sure why it was originally done via a proxy script,
most likely bad legacy design. This is after all one of the oldest
modules...
One side effect of this is that meson doesn't know how to rename
build.CustomTarget files on install (only data files are supported?),
and every file needs to be installed as "domainname.mo" so it must be
named that in-tree too. To prevent clashes, every locale gets its own
locale-specific subdirectory.
Once we are doing that anyway, we can output them to the actual
structure required by the gettext family of functions, and
bindtextdomain() can therefore point to this location if desired. This
might be useful for running localized programs from the build tree.
If POTFILES.in exists, then it will have come from autotools, in which
case it is explicitly the file passed to xgettext -f, and the POTFILES
file itself is generated by autotools as a proxy file which eventually
gets inlined into the final Makefile as a variable "POTFILES = ......"
In this case, attempting to use POTFILES as the input file will simply
result in syntax errors and the inability to find files with a literal
trailing " \" in the name. Usually POTFILES will not exist at all, and
we would fallback on POTFILES.in, but if the source tree happens to be
dirty, this would result in errors. Since it's never going to be right
to use it, we can just do the right thing from the start and carry on.
Without this, building a module in a Flatpak app manifest that is a
newer version of a module already present in the Flatpak runtime will
fail. (The Flatpak file system is a bunch of hard links to readonly
files, which can be replaced but not written to.)
This instead creates a temporary file in the same directory as the
destination (to avoid cross-device renaming errors) and atomically
renames the temporary file to the destination, replacing it instead of
rewriting it as shutil.copyfile() would do.
According to Python documentation[1] dirname and basename
are defined as follows:
os.path.dirname() = os.path.split()[0]
os.path.basename() = os.path.split()[1]
For the purpose of better readability split() is replaced
by appropriate function if only one part of returned tuple
is used.
[1]: https://docs.python.org/3/library/os.path.html#os.path.split
Grammatically, this full stop isn't needed and with file names it has a
potential to be confusing:
Installing /foo/bar/filename.1 to /foo/bar/dirname.
The full stop caused me to do a double-take more than once, so let's drop it.
In the case of subproject we will properly setup the --subdir argument
but the MESON_SUBDIR is never adapted and will point to an empty string
leading to the following backtrace when building `gst-build`:
msgfmt: error while opening "/home/thiblahute/devel/gstreamer/gst-build/af.po" for reading: No such file or directory
Traceback (most recent call last):
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 37, in <module>
sys.exit(main())
File "/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py", line 34, in main
return mesonmain.run(launcher, sys.argv[1:])
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 248, in run
sys.exit(run_script_command(args[1:]))
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/mesonmain.py", line 236, in run_script_command
return cmdfunc(cmdargs)
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 111, in run
if gen_gmo(src_sub, bld_sub, langs) != 0:
File "/home/thiblahute/devel/gstreamer/gst-build/meson/mesonbuild/scripts/gettext.py", line 66, in gen_gmo
'-o', os.path.join(bld_sub, l + '.gmo')])
File "/usr/lib/python3.5/subprocess.py", line 581, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['msgfmt', '/home/thiblahute/devel/gstreamer/gst-build/af.po', '-o', '/home/thiblahute/devel/gstreamer/gst-build/build/af.gmo']' returned non-zero exit status 1
Failed to run install script: /usr/bin/python3 /home/thiblahute/devel/gstreamer/gst-build/meson/meson.py --internal gettext install --subdir=subprojects/gstreamer/po --localedir=share/locale --pkgname=gstreamer-1.0 --langs=af@@az@@be@@bg@@ca@@cs@@da@@de@@el@@en_GB@@eo@@es@@eu@@fi@@fr@@gl@@hr@@hu@@id@@it@@ja@@lt@@nb@@nl@@pl@@pt_BR@@ro@@ru@@rw@@sk@@sl@@sq@@sr@@sv@@tr@@uk@@vi@@zh_CN@@zh_TW
FAILED: install
'/usr/bin/python3' '/home/thiblahute/devel/gstreamer/gst-build/meson/meson.py' '--internal' 'install' '/home/thiblahute/devel/gstreamer/gst-build/build/meson-private/install.dat'
Using 'mesonbuild' as the module can cause it to use the
system-installed module and can also break if we rename the directory,
so avoid that by always using relative imports.
For each project this creates a <project>-update-po target.
When ran this updates the pot file and then merges it back
into the po files in the source directory with `msgmerge`
for project maintainers and translators.
Fixes#819
In autotools POTFILES is generated at configure time from POTFILES.in,
but Meson only looks for a po/POTFILES in the source directory, which
is awkward when trying to maintain both build systems in parallel.
Instead just use POTFILES.in as fallback if it exists but POTFILES
does not. Also print an error if neither exists.
Fixes#818
Eli Schwartz