Sometimes qt can be installed not as framework on MacOS. One way to
achieve this behaviour is to use conan package manager.
Allow falling back to simple library search if framework was
not found. In addition, allow to find the debug version of qt debug
libraries which have "_debug" suffix added to them.
Fixes#5091
There is a comment saying we do it because we used to do it. But it's
wrong and lead to using system library when cross compiling.
Factor out the code we use to find pkg-config, because it is the same
use-case.
Currently PkgConfig takes language as a keyword parameter in position 3,
while the others take it as positional in position 2. Because most
dependencies don't actually set a language (they use C style linking),
using a positional argument makes more sense. ExtraFrameworkDependencies
is even more different, and duplicates some arguments from the base
ExternalDependency class.
For later changes I'm planning to make having all of the dependencies
use the same signature is really, really helpful.
We might be using the 32-bit bits of the VulkanSDK on Windows on x64
Windows, so we still need to pass in the compiler items to detect what
architecture we are building for, so that we link to the correct Vulkan
libraries.
We might want to look into this again if Microsoft will allow ARM/ARM64
versions of the Vulkan drivers and SDK, since post-basic OpenGL and
any Vulkan are not supported on Windows-on-ARM.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
When building for iOS, the Qt binaries only contain static libraries
and headers. No framework.
With this, Meson can successfully compile and link to Qt on iOS
Instead of only doing a naive filesystem search, also run the linker
so that it can tell us whether the -F path specified actually contains
the framework we're looking for.
Unfortunately, `extraframework` searching is still not 100% correct in
the case when since we want to search in either /Library/Frameworks or
in /System/Library/Frameworks but not in both. The -Z flag disables
searching in those prefixes and would in theory allow this, but then
you cannot force the linker to look in those by manually adding -F
args, so that doesn't work.
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.
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()
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
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.
Cerbero
Dylan Baker
nikolayp
Xavier Claessens
Jon Turney
Daniel Mensinger
Chun-wei Fan
Roman Shpuntov
John Ericson
Nirbheek Chauhan
Michael Hirsch, Ph.D
Jan Niklas Hasse
Alexey Rochev
Matthew Waters