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.
Somehow I overlooked this class when adjusting everything else in c59ec874
et seq.
Update Python3Dependency so it has a _factory() method which returns a list
of constructors, depending on the method: kwarg, which integrates better
with the reporting in find_external_dependency()
This ensures the return of a PkgConfigDependency object, if the dependency
is found with pkgconfig, so we don't have to specifically implement
get_pkgconfig_variable() ourselves.
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
This means that we will take into account all the flags set in the
cross file when fetching the list of library dirs, which means we
won't incorrectly look for 64-bit libraries when building for 32-bit.
Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>
Closes https://github.com/mesonbuild/meson/issues/3881
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?
Jon Turney
Dylan Baker
Jussi Pakkanen
Patrick Griffis
Jan Niklas Hasse
GoaLitiuM
Martin Kelly
Alexey Rochev
Jakub Wilk
Rafael Ávila de Espíndola
David Seifert
FFY00
Bruce Richardson
Nirbheek Chauhan