* gtkdoc: Add 'check' kwarg
This runs gtkdoc-check in meson tests.
Also reorganize the gtkdoc test because we cannot reliably build
multiple doc into the same directory. Not all files generated by gtk-doc
are prefixed with the target name.
determine_rpath_dirs() can return paths to external dependencies not
in the build dir and passing them first as a link path leads to
g-ir-scanner for example linking against the already installed library
instead of the just built one.
This was reported in g-i: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/272
and comes up quite often when a library adds some new symbols which aren't present in the
system library, which then makes linking fail.
The first place where the order is changed is _scan_gir_targets(), which looks like an unintentional
change in the refactoring in 8377ea45aa
The second place in _get_link_args() has always been that way and only the rpath order is changed,
but it looks to me as if the same rules should apply here too.
It turns out there's a bug in creating a sub dependency out of threads
in that we pass all of the kwargs from the parent to the
ThreadDependency instance. This demonstrates the bug.
If the detected gpgme version is recent enough to match the version in
which upstream pkg-config files were added, assert that the default
found dependency is of the pkgconfig type.
Import MS-MPI env vars set by installer in registry to environment
Skip testing we can apply a version constraint to MPI when version isn't
known (as is the case for MS-MPI)
(These tests have never worked in appveyor)
using state.subdir will cause / or \ to be inserted into the target name.
Replace them with @ to future-proof it.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>
gtk-doc for autotools has the concept of module version, that is used to define
the module install path and the devhelp2 basename.
Add a `module_version` parameter to gnome.gtkdoc to replicate the same behavior.
Updated the test checking that the install_dir is properly computed (if not
passed), and that the .devhelp2 file has proper name.
https://gitlab.gnome.org/GNOME/gtk-doc/blob/GTK_DOC_1_29/buildsystems/autotools/gtk-doc.make#L269
As it currently stands, if for whatever reason you have two files you
want to merge with the same output name, it will fail due to multiple
targets with the same name due to the target name being autogenerated
from the output kwarg.
Signed-off-by: Marty E. Plummer <hanetzer@startmail.com>