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
macOS provides the tool `lipo` to check the archs supported by an
object (executable, static library, dylib, etc). This is especially
useful for fat archives, but it also helps with thin archives.
Without this, the linker will fail to link to the library we mistakenly
'found' like so:
ld: warning: ignoring file /path/to/libfoo.a, missing required architecture armv7 in file /path/to/libfoo.a
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.
Also ensure that the test's no-pkg-config codepath will always be run,
even on the CI where we always have pkg-config available.
This counts as a test case for #4728
Fixes this annoying warning while running the tests:
mesonbuild/coredata.py:237: DeprecationWarning: The SafeConfigParser
class has been renamed to ConfigParser in Python 3.2. This alias will be
removed in future versions. Use ConfigParser directly instead.
When using pkg.generate(mylib, library : publicdep) it is pretty clear
we don't want to associate publicdep to this generated pkg-config file.
This is a small behaviour break in theory, but also fixes real bug in
the case publicdep is later used to generate another pkg-config file
that does not depend on mylib, that would write a wrong `Requires:
mylib` in the genarated pkg-config file.
This fix unavoidable deprecation warning when glib is cross built
for Android. Glib does `pkg.generate(libglib, libraries : [libintl],
...)` which wrongly associates libintl to the generated glib-2.0.pc, so
when later it generates gio-2.0.pc file that depends on libglib, it will
warn about libintl being associated with libglib. This does not happen
in normal glib build because libintl is usually provided by glibc and is
only an internal library when it fallbacks to a subproject.
The native file tests were never run on the CI since they were skipped
on Windows and also skipped on Linux and macOS since CC/CXX/etc are
always set by the CI.
Also fix test failure on macOS. The test was assuming that because
/usr/bin/gcc and /usr/bin/clang exist on macOS, they must be different
compilers. They're not. gcc is just a wrapper around clang, and we
correctly detect it as such.
This is the second most straight forward stupid way of handling
this (with usiing os.path.exists) as the most stupid obvious way. The
only major advantage is that having .git as something other than a
file or directory still doesn't register.
Fixes: #3378
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.
Previously, the default option string was compared to the actual project
option that has been converted to the proper type. This lead to messages
like 'Option x is: true [default: true]'.
Fixes#4806.
John Ericson
Daniel Mensinger
Nirbheek Chauhan
Michael Hirsch, Ph.D
Jussi Pakkanen
Elliott Sales de Andrade
Olexa Bilaniuk
Xavier Claessens
Dylan Baker
Nicolas Schneider
Nicolas Schneider