The sysconfig config variables are different on MSYS2 and the paths
are also different. We now also use the full path to the import or
static library instead of using -Lfoo -lpython35 etc.
Also obey the value of the 'static' keyword argument.
sysconfig.get_platform() returns 'mingw' with MSYS2, so we need to
use some other method; in this case I chose to use the CC that
Python was compiled with, which is a relatively reliably indicator
unless people start using Python on Windows compiled with Clang or
something.
/usr/bin/env does not exist on Haiku since there's no /usr. The actual
location is /bin/env. Detect that case and directly use the
interpreter being passed to `env` in the shebang.
Also reorganize the Windows special cases which does the same thing.
The MinGW toolchain can read MinGW paths, but Python cannot and we
sometimes need to parse the libs and cflags manually (for static-only
library searching, for instance). The MinGW toolchain can always read
Windows paths with `/` as path separater, so just use that.
Also try harder to find a compiler that dependencies can use.
This means that in C++-only projects we will use the C++ compiler for
compiler checks, which can be important.
MSVC cannot handle MinGW-esque /c/foo paths, convert them to C:/foo.
We cannot resolve other paths starting with / like /home/foo so leave
them as-is so the user gets an error/warning from the compiler/linker.
These paths are commonly found in pkg-config files generated using
Autotools inside MinGW/MSYS and MinGW/MSYS2 environments.
Currently this is only done for PkgConfigDependency.
While finding an external program, we should only split the shebang
once since that is what Linux and BSD also do. This is also why
everyone uses #!/usr/bin/env in their shebangs since that allows
you to run an interpreter in a path with spaces in it.
See `man execve` for more details, specifically the sections for
interpreter scripts.
Some dependencies can be detected multiple ways, such as a config tool
and pkg-config. For pkg-config a new PkgConfigDependency is created and
used to check for the dependency, config tool dependencies are handled
ad-hoc. This allows the ConfigToolDependency to be used in the same way
that PkgConfigDependency is.
This class is meant abstract away some of the tedium of writing a config
tool wrapper dependency, and allow these instances to share some basic
code that they all need.
This basically boils down to using map() and expecting a list, but map
returns an iterator. The better solution is to use a list comprehension
anyway, so do that.
Just detect lrelease as done with other Qt tools.
Uses -version instead of -v to probe version since lrelease don't
support it.
Signed-off-by: Alexis Jeandet <alexis.jeandet@member.fsf.org>
pkg-config enables to define variables by using the define-variable
option. This allows some packages to redefine relative paths, so
files can be installed in the same relative paths but under prefix.
BOOST_LIBS could become outdated in future versions, which would result
in dependency('boost', modules : [ 'foo' ], required : false) to fail,
although required was set to false. Therefore turn the exception into
log_fail(). If required was set to true, this will still be caught since
is_found remains False.
This also improves logging by printing all invalid module names instead
of only the first one.
f.ex when you don't have the llvm-static package installed, the error
message when generating libs is cryptic and uninformative since we
discard stderr.
Sometimes pkg-config can decide that the libdir is a system library dir
and must not be included in the output because that would mess up the
library search order for pkg-config libraries that must be sourced from
a non-system prefix.
However, when we're doing manual searching, we always want to see the
library directory even if it's the system path, otherwise we can't do
manual searching at all.
Escaping spaces with '\ ' is the only way that works with both
pkg-config and pkgconf, so quote that way and unquote inside Meson.
This should work on all platforms.
Also fix the unit test to do the same.
https://github.com/pkgconf/pkgconf/issues/153
When `static: true` is passed to dependency(), we parse the pkg-config
output and manually search for `-lfoo`, etc in the library paths
gathered from `-Lbar` arguments in the output.
If there are no `-L` arguments in the output, the behaviour is the
same as before. If there are `-L` arguments and we can't find a static
library, we will error out.
We can now specify the library type we want to search for, and whether
we want to prefer static libraries over shared ones or the other way
around. This functionality is not exposed to build files yet.
LLVM >= 3.9 provides an llvm-config that has a sane mechanism for
selecting static vs dynamic linking. LLVM < 3.9 (but >= 3.5) not so
much. For those older LLVM versions, llvm-config will always provide
arguments for statically linking LLVM, even if there is a library for
dynamic linking.
Fixes#2442
PkgConfig automatically removes -L paths from libdirs if the -L points
to a system path. It knows what these paths are by taking this as a
configure option at build time, which the distro maintainers set
appropriately and everything works. This allows one to have two
versions of a package installed, a system and non system, and then
override PKG_CONFIG_PATH to use the non system version, and everything
just works. For non-pkgconfig dependencies (such as LLVM) meson needs to
strip these themselves to avoid breaking the above use case.
Nirbheek Chauhan
Niklas Claesson
Iñigo Martínez
Josh Soref
Dylan Baker
Alexis Jeandet
Jussi Pakkanen
Joergen Ibsen
Anonymous Maarten
Jan Niklas Hasse
Félix Piédallu
Goncalo Carvalho
Niklas Claesson