If a `<modulename>-overrides.txt` file exists in the docs directory it
means it's intended to be used in place of the one gtk-doc generates.
GLib and GTK+, for instance, ship with one because some of the types
they provide — like the thread primitives, or the platform macros —
contain architecture-dependent fields that should not be accessed
directly.
This commit should close the last bit of issue #550.
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
Allowing the object tree to be generated.
We need to add options to allow copying the ncesseary sources and
assets so the HTML generator can work with them (everything is
relative so we need to copy them in the build directory).
Until now the documentation was not generated from the user provided
main sgml file but it was using a generated one, which lead to a broken
documentation. Starting using it revealed the other bugs fixed in that
commit.
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
Passing an absolute path to `install_dir` would previously always
attempt to install there, instead of obeying DESTDIR, since os.path.join
will 'reset' on absolute paths.
For commands that always output to stdout and don't have a "-o" or
"--output" or some other similar option, this 'capture' setting allows
the build to capture the result and place it in the output file.
The Meson script is not always in $scriptdir/../../ -- for instance if
installed with pip on Windows, the scriptdir is in:
C:/Python35/Lib/site-packages/meson-0.33.0.dev1-py3.5.egg/mesonbuild/scripts
and the meson.py script is in:
C:/Python35/Scripts
So, let's save the path available as Environment().meson_script_file
into the coredata.dat private file and use that to invoke Meson when
doing regen.
Also, let's fetch the backend that was used from the coredata too
instead of hard-coding vs2010.
Both these were causing a hard failure while doing regen with msbuild or
visual studio.
Do not modify the wrap command argument from the calling function.
Appending the valgrind arguments to the wrap list argument will cause all
the valgrind arguments to cumulate from all the tests to the wrapper
command itself.
The extra arguments are typically used to specified the location of
installed API references that gtk-doc can use to create cross links
for symbols.
Fixes#555
When a CustomTarget is run with a command that is an executable built
by the project which also has a DLL built in the same project as a
dependency, the EXE can't run on Windows because the DLL can't be found.
On UNIX-like systems, we set the RPATH using the linker so these
dependencies can be found, but on Windows the only way is to set the
PATH environment variable.
The same problem exists for tests, so we reuse that infrastructure by
creating a new meson_exe.py script that can be used as a wrapper to run
CustomTarget commands on Windows. This can later also be extended to add
support for setting an environment while calling the command needed to
generate a CustomTarget: https://github.com/mesonbuild/meson/issues/266
Emmanuele Bassi
Aurelien Jarno
Patrick Griffis
Hemmo Nieminen
Jussi Pakkanen
Thibault Saunier
Tim-Philipp Müller
Thibault Saunier
Elliott Sales de Andrade
Nirbheek Chauhan
Nirbheek Chauhan
Minijackson
trhd
Nicolas Schneider