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>
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 /
With this it is now possible to do
foobar = executable('foobar', ...)
meson.override_find_program('foobar', foobar)
Which is convenient for a project like protobuf which produces both a
dependency and a tool. If protobuf is updated to use
override_find_program, it can be used as
protobuf_dep = dependency('protobuf', version : '>=3.3.1',
fallback : ['protobuf', 'protobuf_dep'])
protoc_prog = find_program('protoc')
fixes#4032: meson now checks properly for the compiler used to compile dub dependencies
fixes#3568: applied the following patch https://paste.debian.net/1039317/
meson now adds flags for native dependencies required by dub modules
meson now checks for the D version implemented by the compiler used to build dub dependencies (execpt gdc which doesn't support this)
At the moment, this check only exists for pkg-config dependencies (and dub,
where the code is cut-and-pasted)
Factor it out and apply it to all dependency type
pkg-config and pkgconf treat additional search paths in
PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR differently when
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 is set.
pkg-config always outputs -L flags for the additional paths first, and
pkgconf always outputs -L flags for the default paths first.
To account for this inconsistency, we now sort the library paths into
two separate sets: system (default) and prefix (additional) paths. We
can do this because we always query pkg-config twice: once with
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 set and once without it.
Then, we ensure that the prefix paths are searched before the system
paths.
Closes https://github.com/mesonbuild/meson/issues/4023
Closes https://github.com/mesonbuild/meson/issues/3951
These weren't caught by the CI because we have pkg-config on it, and
these were testing non-pkg-config codepaths. The unity build on macOS
now doesn't have pkg-config to ensure that the codepath is tested.
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.
Michael Hirsch, Ph.D
Daniel Mensinger
Nirbheek Chauhan
John Ericson
Xavier Claessens
John Ericson
Jon Turney
Dylan Baker
Lyude Paul
GoaLitiuM
Martin Kelly
Rafael Ávila de Espíndola
FFY00