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.
For some reason this was missing, but it should've always existed
since cc.find_library() returns an object that is internally an
ExternalDependency instance.
Those tools use our arguments to build a file and execute it to
introspect it at runtime. However, they do not know that you can pass
the full path to the library to use, and ignore the arguments.
The long-term fix for this is to have them output a .c file that Meson
will build for them, which they can then run, but that will require
upstream changes:
https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/1
Closes https://github.com/mesonbuild/meson/issues/3774
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
* Add a test case for bad de-dup of -framework args
https://github.com/mesonbuild/meson/issues/3800
* pkgconfig: Don't naively de-dup all arguments
Honestly don't know what I was smoking. Of course the `Libs:` field in
a pkg-config file can have arguments other than -l and -L
Closes https://github.com/mesonbuild/meson/issues/3800
* pkgconfig module: Fix needlessly aggressive de-dup
The name splitting was wrong and would not incorrectly handle folders
with two dots, like Foo.framework.dSYM and treat this as 'Foo' instead
of 'Foo.framework', which would lead to meson detecting dSYM bundles
as frameworks and try to use those like a framework, which is wrong.
Fix#3793
D is not a 'c-like' language, but it can link to C libraries. The same
might be true of Rust in the future and Go when we add support for it.
This contains no functionality changes.
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.
Currently, ExternalProgram get_path() assumes the last component in the
path is always the actual command path. However, this is not always
right. For example, in the command "python -u", we should return
"python" and not "-u". However, in other cases, like "python script.py",
then the last component is the right one.
The heuristic that seems to capture this is to use the last argument
that is still a file. This means options get ignored, but "python
script.py" still works. Let's use this heuristic, at least for now.
This adds a new method, partial_dependency to all dependencies. These
sub dependencies are copies of the original dependency, but with one or
more of the attributes replaced with an empty list. This allows creating
a sub dependency that has only cflags or drops link_arguments, for
example.
This halves the configure time in gst-build, the aggregate of all
GStreamer repositories.
We can't do this to Popen_safe because we can't be sure that other
programs have no side-effects and will always return the same output
for the same arguments and environment.
Strawberry Perl on Windows ships with a Perl implementation of
pkg-config embedded inside a BAT file. True horror of horrors, but
people do use it, so search for pkg-config with ExternalProgram which
has the right Windows-specific cases to deal with that.
Closes https://github.com/mesonbuild/meson/issues/3221
Unusually, the cygwin package for openmpi installs headers into
/usr/include, rather than /usr/include/openmpi
Prevent pkg-config from suppressing that -I flag, so a gfortran INCLUDE can
find those files
Also don't resolve -lfoo args only when libpaths are defined.
cc.find_library() also searches in the toolchain directories, and the
static library might be there.
Jon Turney
Dylan Baker
GoaLitiuM
Martin Kelly
Rafael Ávila de Espíndola
FFY00
Nirbheek Chauhan
Nirbheek Chauhan
Christopher Dunn
Marvin Scholz
Elliott Sales de Andrade
Aleksey Filippov