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.
Also add a test for it. In the process, also remove an overly-zealous
try..except statement that was catching *all* exceptions, not just
expected ones, which was masking programming errors.
.get_command() will return None when it's not found, so there's no
point trying to print that. Print self.name instead, which is what
we tried to search for.
First, I noticed there was a dangling use of now-removed cross_info in
the CMake lookup. No tests had caught this, but it means that CMake deps
were totally broken. [It also meant that CMake could not be specified
from a native file.]
In a previous of mine PR which removed cross_info, I overhauled finding
pkg-config a bit so that the native and cross paths were shared. I
noticed that the CMake code greatly resembled the pkg-config code, so I
set about fixing it to match.
I then realized I could refactor things further, separating caching,
finding alternatives, and validating them, while also making the
validations less duplicated. So I ended up changing pkg config lookup a
lot too (and CMake again, to keep matching).
Overall, I think I have the proper ideom for tool lookup now, repated in
two places. I think it would make sense next to share this logic between
these two, compilers, static linkers, and any other tool similarly
specifiable. Either the `BinaryTable` class in environment.py, or a new
class for `Compiler` and friends to subclass, would be good candidates
for this.
In recent change, dependency('foo') does not return a not-found
PkgConfigDependency any more, but a NotFoundDependency object. This
creates a regression in gst-build that does
dependency('foo').get_partial_dependency() causing Meson to raise an
exception.
The returned not-found object can be from any type because we were
returning the first of the failed attempts. It also can happen that we
don't have any dependency object in which case we should just return
NotFoundDependency() object as well instead of raising an exception.
That exception was happening before, but dependency_impl() was
calling find_external_dependency() in a try block so it was hidden.
When req_version is None (e.g. pcap-config case) it gets printed in the
logs.
Take this opportunity to reformat the message to look more like
ExternalProgram messages.
When trying to cross-compile mesa on an aarch64 system, I noticed some
strange behavior. Meson would only ever find the wayland-scanner binary
in my host machine's sysroot (/mnt/amethyst):
Native dependency wayland-scanner found: YES 1.16.0
Program /mnt/amethyst/usr/bin/wayland-scanner found: YES (/mnt/amethyst/usr/bin/wayland-scanner)
It should be finding /usr/bin/wayland-scanner instead, since the
wayland-scanner dependency is created as native. On closer inspection,
it turned out that meson was ignoring the native argument passed to
dependency(), and wuld always use the pkgconfig binary specified in my
toolchain instead of the native one (/usr/bin/pkg-config):
Native dependency wayland-scanner found: YES 1.16.0
Called `/home/lyudess/Projects/panfrost/scripts/amethyst-pkg-config
--variable=wayland_scanner wayland-scanner` -> 0
Turns out that if we create a dependency() object with native:false, we
end up caching the pkg-config path for the host machine in
PkgConfigDependency.class_pkgbin, instead of the build machine's
pkg-config path. This results causing in all pkg-config invocations for
dependency() objects to use the host machine's pkg-config binary,
regardless of whether or not 'native: true' was specified when the
dependency() object was instantiated.
So, fix this by never setting PkgConfigDependency.class_pkgbin for cross
dependency() objects. Also, add some test cases for this. Since
triggering this bug can be avoided by creating a dependency() objects
with native:true before creating any with native:false, we make sure
that our test has two modes: one where it starts with a native
dependency first, and another where it starts with a cross dependency
first.
As a final note here: We currently skip this test on windows, because
windows doesn't support directly executing python scripts as
executables: something that we need in order to point pkgconfig to a
wrapper script that sets the PKG_CONFIG_LIBDIR env appropriately before
calling pkg-config.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
Handle clang's cl or clang-cl being in PATH, or set in CC/CXX
Future work: checking the name of the executable here seems like a bad idea.
These compilers will fail to be detected if they are renamed.
v2:
Update compiler.get_argument_type() test
Fix comparisons of id inside CCompiler, backends and elsewhere
v3:
ClangClCPPCompiler should be a subclass of ClangClCCompier, as well
Future work: mocking in test_find_library_patterns() is effected, as we
now test for a subclass, rather than self.id in CCompiler.get_library_naming()
As mentioned in #4407, if dependency('boost') fails, the error message
is 'Dependency "boost" not found, tried' (sic).
Similar to line 1451 above, suppress reporting the tried methods
returned by log_tried(), if the list is empty (as is the case with
boost)
Replace '\\' with \\\\ in config values args. Otherwise shlex will
helpfully remove path separators on windows, resulting in values like:
`-Ic:mydataishere`
fixup! dependencies/base: Replace windows path separators with /
Instead of trying to hardcode which versions of which OSes are
misconfiguring llvm-config, lets try to use a generic mechanism that
catches most of the broken cases.
If a dynamic lib is built but the tools are linked staticly
(LLVM_BUILD_LLVM_DYLIB=true and LLVM_LINK_LLVM_DYLIB=false) and you
don't enabled shared libs (LLVM_BUILD_SHARED_LIBS=false, which should be
false), then llvm-config will mistakenly return a each static library
with .(so|dll|dylib) appended, instead of -lLLVM-x.y.z. if
LLVM_LINK_LLVM_DYlIB is true this works fine. There's been a bug opened
in upstream since 2014 about this with no responses[1].
So, this patches looks at --shared-mode (which tells us whether
llvm-config was linked staticly or dynamicly), then if the shared-mode
is static it will check and see what it gets. If it gets valid results
then it will go with those, if it doesn't then it will try to build a
set of valid link arguments to link with libLLVM.(so|dll|dylib).
[1] https://bugs.llvm.org/show_bug.cgi?id=19937
The versions of LLVM provided by brew have the same configuration problem that
dragonflyBSD and FreeBSD do, which means that they produce wrong results for
shared linking.
It appears that debian has changed their naming scheme. This might
require revisiting in the future to add llvm-config-7.0 if debian
decides to do that.
Nirbheek Chauhan
Michael Hirsch, Ph.D
Daniel Mensinger
John Ericson
Xavier Claessens
Dylan Baker
John Ericson
Jon Turney
Lyude Paul
Jussi Pakkanen
Patrick Griffis
Jan Niklas Hasse
GoaLitiuM