When meson is currently being run with a python that seems to have been
installed from the Windows Store, replace the general WindowsApps
directory in search paths with dirname(sys.executable), and also handle
failures with pathlib.resolve on WindowsApps exe files.
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
The system tool is always the wrong thing to use and cause hard to debug
issues when trying to link system libraries with cross built binaries.
The ExternalDependency base class already had a method to deal with
this, used by PkgConfigDependency and QtBaseDependency, so it should
make things more consistent.
Doing this by hand is fraught with corner cases, and we're running into
some of those problems already. setuptools pkg_resource is a well tested
solution for not running into corner cases, and we already rely on
setuptools to make our entry point scripts work, so we might as well
make us of the other things it can solve for us.
Fixes#6801
When taking library dependencies from CMake, we first attempt to look
the dependency up in the target list, then fall back to treating it as a
path, which we add if the path exists.
As there is no check for whether or not the path is really a path, this
can cause false positives; for example if a 'uuid' dependency was passed
intending to be a target, but it cannot be found and the current
directory also contains a file or directory named 'uuid', we will just
include the string 'uuid' in library dependencies.
This is particularly prevalent on Windows, where a system library called
'version' exists, and thanks to case insensitivity will match a file
called 'VERSION' if found in the source root when running Meson from the
source directory, or a generated file when running Meson from the build
directory.
Fix this check to only look up filesystem existence on absolute paths,
not unqualified.
This also adds a fallback warning in case an argument cannot be found,
rather than silently falling back.
On Windows, library dependencies can be passed with no prefix or suffix;
rather than -lfoo or foo.dll, they can just be passed as 'foo'.
CMake handles this and suffixes the library with '.lib' or '.dll',
depending on the link mode.
Do the same here, and if we've been passed an unqualified non-option
bare name on Windows, add the appropriate suffix and pass it through to
the linker. This fixes dependencies on system libraries.
When finding dependencies from CMake, use a smarter regex to determine
whether or not a dependency is actually a link argument, and pass
through Windows link arguments properly.
Compiler is invariant, in other words Compiler and only Compiler can
fulfull it, it's derived classes cannot be used. CompilerType is
covariant, that is Compiler and any derived class can fulfill it. This
fixes a number of issues in the boost module.
This leads to better version parsing. An concrete example use case is
llc. When invoking llc with "--version", the output is
```
LLVM (http://llvm.org/):
LLVM version 9.0.1
...
```
The old version parsing recognizes the dot in the first line as version.
This commit also tries to adapt the two regexes to each other.
Reported-by: Björn Fiedler <fiedler@sra.uni-hannover.de>
There is a comment saying we do it because we used to do it. But it's
wrong and lead to using system library when cross compiling.
Factor out the code we use to find pkg-config, because it is the same
use-case.
The CMake config files / modules have to be checked
case insensitive in some cases, otherwise some dependencies
will not be found even though they are installed.
Instead of using dependencies as their own factories, which is rather
odd, lets just add a dedicated DependencyFactory class. This should be
able to take over for a lot of the factory type dependencies really
easily, and reduce the amount of code we have.
Currently PkgConfig takes language as a keyword parameter in position 3,
while the others take it as positional in position 2. Because most
dependencies don't actually set a language (they use C style linking),
using a positional argument makes more sense. ExtraFrameworkDependencies
is even more different, and duplicates some arguments from the base
ExternalDependency class.
For later changes I'm planning to make having all of the dependencies
use the same signature is really, really helpful.
This moves most of the execution code from the CMakeInterpreter
into CMakeExecutor. Also, CMakeTraceParser is now responsible
for determining the trace cmd arguments.
The latest Windows 10 release in May 2019 added zero-sized files that
act as stubs which when launched from cmd.exe spawn the Windows Store
to install those apps. This also includes python.exe and python3.exe:
https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/
Unfortunately, `import('python').find_installation('python3')` will
then think that python3.exe is available on Windows. Or, worse, if the
user has a fresh installation of Windows 10 and then installs the
Python 3 using the official installer (not the Windows Store app), we
will *still* pickup this stub because it will be first in `PATH`.
Always remove the WindowsApps directory from `PATH` while searching.
First reported at https://gitlab.freedesktop.org/gstreamer/cerbero/issues/223
declare_dependencies
This allows dependencies declared in subprojects to set variables, and
for those variables to be accessed via the get_variable method, just
like those from pkg-config and cmake. This makes it easier to use
projects from subprojects in a polymorphic manner, lowering the
distinction between a subproject and an external dependency every
further.
When there is more than one path in PKG_CONFIG_PATH. It is almost always
preferred to find things in the order specified by PKG_CONFIG_PATH
instead of assuming pkg-config returns flags in a meaningful order.
For example:
/usr/local/lib/libgtk-3.so.0
/usr/local/lib/pkgconfig/gtk+-3.0.pc
/usr/local/lib/libcanberra-gtk3.so
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc
/home/mesonuser/.local/lib/libgtk-3.so.0
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig:/usr/local/lib/pkgconfig"
libcanberra-gtk3 is a library which depends on gtk+-3.0. The dependency
is mentioned in the .pc file with 'Requires', so flags from gtk+-3.0 are
used in both dynamic and static linking.
Assume the user wants to compile an application which needs both
libcanberra-gtk3 and gtk+-3.0. The application depends on features added
in the latest version of gtk+-3.0, which can be found in the home
directory of the user but not in /usr/local. When meson asks pkg-config
for linker flags of libcanberra-gtk3, pkg-config picks
/usr/local/lib/pkgconfig/libcanberra-gtk3.pc and
/home/mesonuser/.local/lib/pkgconfig/gtk+-3.0.pc. Since these two
libraries come from different prefixes, there will be two -L arguments
in the output of pkg-config. If -L/usr/local/lib is put before
-L/home/mesonuser/.local/lib, meson will find both libraries in
/usr/local/lib instead of picking libgtk-3.so.0 from the home directory.
This can result in linking failure such as undefined references error
when meson decides to put linker arguments of libcanberra-gtk3 before
linker arguments of gtk+-3.0. When both /usr/local/lib/libgtk-3.so.0 and
/home/mesonuser/.local/lib/libgtk-3.so.0 are present on the command
line, the linker chooses the first one and ignores the second one. If
the application needs new symbols that are only available in the second
one, the linker will throw an error because of missing symbols.
To resolve the issue, we should reorder -L flags according to
PKG_CONFIG_PATH ourselves before using it to find the full path of
library files. This makes sure that we always follow the preferences of
users, without depending on the unreliable part of pkg-config output.
Fixes https://github.com/mesonbuild/meson/issues/4271.
access(2) tests for X_OK that return true do not always guarantee that
the file is executable. Instead check the stat(2) mode bits explicitly.
This fixes any builds or installs executed as root on Solaris and
illumos that contain non-executable scripts.
cmake: get language from Meson project if not specified as depedency(..., langugage: ...)
deps: add threads method:cmake
dependency('threads', method: 'cmake') is useful for cmake unit tests
or those who just want to find threads using cmake.
cmake: project(... Fortran) generally also requires C language
Some slight refactoring for the dependency classes and
I switched the elbrus compiler to the GnuLikeCompiler.
This is also the correct use according to the documentation
of GnuLikeCompiler.
Daniel Mensinger
D Scott Phillips
Dylan Baker
Alexander Neumann
Xavier Claessens
Daniel Stone
John Ericson
Gerion Entrup
Max
Stéphane Cerveau
Nirbheek Chauhan
Michael Hirsch, Ph.D
Ting-Wei Lan
Jonathan Perkin
Jussi Pakkanen