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>
When an older version of the library being built is installed in the
same prefix as external dependencies, we have to be careful to construct
the linker or compiler command line. If a -L flag from external
dependencoes comes before a -L flag pointing to builddir, it is possible
for the linker to load older libraries from the installation prefix
instead of the newly built ones, which is likely to cause undefined
reference error.
Since the order of dependencies is not significant, we cannot expect
internal dependencies to appear before external dependencies when
recursively iterating the list of dependencies. To make it harder to
make mistakes, linker flags come from internal and external
dependencies are now stored in different order sets. Code using
_get_dependencies_flags are expected to follow the order when
constructing linker command line:
1. Internal linker flags
2. LDFLAGS set by users
3. External linker flags
It is similar to what automake and libtool do for autotools projects.
We were setting it to a file list that would always be wrong, and
always out of date since it would never exist.
However, the output list is not predictable. It usually has a 1-1
relationship with the input XML files, but it may not.
This must be fixed later with API for users to provide the output
names.
See: https://github.com/mesonbuild/meson/pull/3539
If we pass a source files() object, we will look for it in the build
directory, which is wrong. If we pass a build files() object (from
configure_file()), we will find it in the build directory, and then
try to copy it on top of itself in gtkdochelper.py getting a
SameFileError.
Add a test for it, and also properly iterate custom target outputs
when adding to content files.
Jussi Pakkanen
Daniel Mensinger
Dylan Baker
Konstantin
Eli Schwartz
Jan Tojnar
Michael Hirsch, Ph.D
Michael Hirsch, Ph.D
Alexis Jeandet
Thibault Saunier
Jon Turney
Nicole Mazzuca
xiannox
TingPing
Masanori Kakura
Marty E. Plummer
Marco Trevisan (Treviño)
Alexey Rochev
Corentin Noël
Mathieu Duponchelle
Nirbheek Chauhan
Ting-Wei Lan
Corentin Noël