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.
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.
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>
Dylan Baker
Jon Turney
Daniel Mensinger
Chun-wei Fan
Roman Shpuntov
John Ericson
Nirbheek Chauhan
Michael Hirsch, Ph.D
Jan Niklas Hasse
Alexey Rochev
Matthew Waters
Xavier Claessens
Salamandar
Jussi Pakkanen
Alexis Jeandet