If we aren't cross-building, this distinction isn't very interesting
(Most dependencies didn't bother reporting this. pkgconfig did it
unconditionally, and Qt reported as 'native' or 'cross' depending on
is_cross_build(), i.e. ignoring the native: keyword)
If successful, we should identify the method which was successful
If successful, we should report the version found (if known)
If failing, we should identify the methods we tried
Some dependency detectors which had no reporting now gain it
There's all kinds of complexities, inconsistencies and special cases hidden
in the existing behaviour, e.g.:
- boost reports modules requested, and BOOST_ROOT (if set)
- gtest/gmock report if they are a prebuilt library or header only
- mpi reports the language
- qt reports modules requested, and the config tool used or tried
- configtool reports the config tool used
- llvm reports if missing modules are optional (one per line)
We add some simple hooks to allow the dependency object to expose the
currently reported information into the consolidated reporting
Note that PkgConfigDependency() takes a silent: keyword which is used
internallly to suppress reporting. This behaviour isn't needed in
find_external_dependency().
Give ConfigToolDependency() a finish_init callback, so that tool-specific
initialization can be called from the constructor, rather than after
construction in the factory class.
v2:
finalize -> finish_init for clarity
find_external_dependency() now makes and iterates over a list of callables
which are constructors with bound arguments for the dependency objects we
are going to attempt to make, so we can consolidate reporting on these
attempts and handling failures in that function.
dub dependencies allegedly support method:pkgconfig, but this is meaningless
as it's only ever used when the dub method is explicitly requested.
Possibly cut-and-pasted from elsewhere?
We already have code to fetch and find binaries specified in a cross
file, so use the same code for exe_wrapper. This allows us to handle
the same corner-cases that were fixed for other cross binaries.
For some reason this was missing, but it should've always existed
since cc.find_library() returns an object that is internally an
ExternalDependency instance.
We now pass the current subproject to every FeatureNew and
FeatureDeprecated call. This requires a bunch of rework to:
1. Ensure that we have access to the subproject in the list of
arguments when used as a decorator (see _get_callee_args).
2. Pass the subproject to .use() when it's called manually.
3. We also can't do feature checks for new features in
meson_options.txt because that's parsed before we know the
meson_version from project()
Those tools use our arguments to build a file and execute it to
introspect it at runtime. However, they do not know that you can pass
the full path to the library to use, and ignore the arguments.
The long-term fix for this is to have them output a .c file that Meson
will build for them, which they can then run, but that will require
upstream changes:
https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/1
Closes https://github.com/mesonbuild/meson/issues/3774
A number of cases have to be taken care of while doing this, so
refactor it into a helper on ExternalProgram and use it everywhere.
1. Command is a list of len > 1, use it as-is
2. Command is a list of len == 1 (or a string), use as a string
3. If command is an absolute path, use it as-is
4. If command is not an absolute path, search for it
* Add a test case for bad de-dup of -framework args
https://github.com/mesonbuild/meson/issues/3800
* pkgconfig: Don't naively de-dup all arguments
Honestly don't know what I was smoking. Of course the `Libs:` field in
a pkg-config file can have arguments other than -l and -L
Closes https://github.com/mesonbuild/meson/issues/3800
* pkgconfig module: Fix needlessly aggressive de-dup
The name splitting was wrong and would not incorrectly handle folders
with two dots, like Foo.framework.dSYM and treat this as 'Foo' instead
of 'Foo.framework', which would lead to meson detecting dSYM bundles
as frameworks and try to use those like a framework, which is wrong.
Fix#3793
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
All dependencies were using find_library, has_header, get_define, etc on
self.compiler assuming that it's a compiler that outputs and consumes
C-like libraries. This is not true for D (and in the future, for Rust)
since although they can consume C libraries, they do not use the
C ecosystem.
For such purposes, we now have self.clib_compiler. Nothing uses
self.compiler anymore as a result, and it has been removed.
debugoptimized builds building against Qt would ultimately link against
both the debug and non-debug msvcrt, ntdll, etc libraries which causes
crashes in weird places and is very much not recommended by Microsoft.
This changes the selected Qt library(ies) correctly to not uses the
debug variants for debugoptimized builds.
https://github.com/mesonbuild/meson/pull/3680
This reverts commit 0045d95a16.
<jeandet> nirbheek, it seems 0045d95a16 is
really wrong, I've tested on Ubuntu. While writing this line I was
thinking that you can't have Qt without a working qmake in the path. On
Ubuntu you have that qtchooser stuff which is misleading.
Currently, ExternalProgram get_path() assumes the last component in the
path is always the actual command path. However, this is not always
right. For example, in the command "python -u", we should return
"python" and not "-u". However, in other cases, like "python script.py",
then the last component is the right one.
The heuristic that seems to capture this is to use the last argument
that is still a file. This means options get ignored, but "python
script.py" still works. Let's use this heuristic, at least for now.
Removed Qt4 private headers test since it's hard to get Qt4 private
headers installed on CI.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This commit adds private_headers option in dependency method which tells
QtDependency to add private headers include path to build flags.
Since there is no easy way to do this with pkg-config only qmake method
supports this, so with private_headers set qmake will always be used.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
This adds a new method, partial_dependency to all dependencies. These
sub dependencies are copies of the original dependency, but with one or
more of the attributes replaced with an empty list. This allows creating
a sub dependency that has only cflags or drops link_arguments, for
example.
This halves the configure time in gst-build, the aggregate of all
GStreamer repositories.
We can't do this to Popen_safe because we can't be sure that other
programs have no side-effects and will always return the same output
for the same arguments and environment.
Strawberry Perl on Windows ships with a Perl implementation of
pkg-config embedded inside a BAT file. True horror of horrors, but
people do use it, so search for pkg-config with ExternalProgram which
has the right Windows-specific cases to deal with that.
Closes https://github.com/mesonbuild/meson/issues/3221
ExtraFrameworkDependency doesn't support any method: other than auto, so
handing down the method: used from QtBaseDependency leads to (sic):
meson.build:13:2: ERROR: Unsupported detection method: qmake, allowed methods are auto and auto
Jon Turney
Derek Kingston
FFY00
Nirbheek Chauhan
Nirbheek Chauhan
Christopher Dunn
Marvin Scholz
Matthew Waters
Xavier Claessens
Salamandar
Martin Kelly
Jussi Pakkanen
David Seifert
Alexis Jeandet
Dylan Baker
Elliott Sales de Andrade
Jukka Laurila
Aleksey Filippov