Instead of blindly searching in PATH, use
Qt5Dependency.compilers_detect() (same for qt4) to get moc/uic/rcc.
This is much more robust, and it improves the chances that the correct
ones will be found. We still manually verify for now because the
fallback in dependencies.py for searching is stll to look in PATH for
backwards-compat, and because people probably have setups like that.
Also sync the qt4 module with the qt5 module w.r.t. resource compilation
and make the compiled qrc.cpp file unique in terms of the framework
version used (4 vs 5). This is needed for the test to work properly,
which now covers both Qt4 and 5.
Without this a strange exception is spewed that no one would be able to
understand. Finding each of those compilers isn't a problem unless
sources are specified that require those compilers, so only error out in
those cases.
Closes#758
- Use depfile support on recent glib-compile-resources
- Don't pass dep files to header ever
- Pass depends for generated deps
- Avoid duplicate --sourcedir args
- Include correct subdir of generated deps
If building in a prefix with a version of the library that's already
installed with other dependencies already installed in that prefix,
then the installed library was being picked up to link with
for gir generation instead of the newly built library.
Not all headers are public, or contain public types. GTK-Doc allows
adding headers to be ignored during the "scan" phase, by passing the
`--ignore-headers` command line argument to gtkdoc-scan.
Currently, you can do something like:
ignored_headers = [ 'foo-private.h', 'bar-private.h', ]
gnome.gtkdoc(...
scan_args: [
'--ignore-headers=' + ' '.join(ignored_headers),
],
...)
But it does not guarantee escaping rules and it's definitely not nice.
We can add a simpler version of that mechanism through a new positional
argument, `ignore_headers`, which behaves like `content_files` or
`html_assets`, and takes an array of header files to ignore:
gnome.gtkdoc(...
ignore_headers: ignored_headers,
...)
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
This commit adds a 'dependencies' keyword to the
gnome.compile_resources() function, which allows your resource blob
to depend on files generated at build-time from custom_target() or
configure_file() targets.
My current use case for this is source data that gets processed with Gettext
translation tools before being compiled into the resource blob.
This feature only works with GLib version 2.48.2 and above. So the
compile_resources() function now detects GLib version and raises an
error if the version of GLib being used is too old.
The compile_resources() test case is now split into two, so that the
existing one can continue to run on systems with old GLib versions (such
as Ubuntu Xenial, which the automated tests on travisci.org use), but
where new enough GLib is available we also test generating gresource
content.
The existing warning about glib-compile-resources is now only printed
if GLib version is older than 2.50.0 because
<https://bugzilla.gnome.org/show_bug.cgi?id=745754> is fixed in the
2.50.0 release.
Sometimes people want the library to start with 'lib' everywhere, which
is achieved by setting name_prefix to '' and the target name to
'libfoo'. In that case, try to get the pkg-config '-lfoo' arg right.
Also, don't warn about anything on Windows
Fixes https://github.com/mesonbuild/meson/issues/889
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.