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.
This means that when either cflags or libs lookup fails, this will be
logged always in the log, leading to much easier to debug messages
like:
Called `/usr/local/bin/pkg-config --cflags gnutls` -> 1
pkg-config error with 'gnutls': Could not generate cargs for gnutls:
Package nettle was not found in the pkg-config search path.
Perhaps you should add the directory containing `nettle.pc'
to the PKG_CONFIG_PATH environment variable
Package 'nettle', required by 'gnutls', not found
Run-time dependency gnutls found: NO (tried pkgconfig)
Previously even when meson failed to obtain cflags or libs for a
dependency it would lead to the dependency being found, causing very
confusing errors at build time.
Under Windows, the colon ':' is used after the drive letter.
So, the colon should not be used as a list separator or for splitting,
otherwise it could lead to paths in CMAKE_PREFIX_PATH with a
semicolon ';' between the drive letter and the rest of the path, e.g:
-DCMAKE_PREFIX_PATH=C;/foo/bar
instead of
-DCMAKE_PREFIX_PATH=C:/foo/bar
Use os.pathsep instead of ':' to split the environmental variable
CMAKE_PREFIX_PATH
Most apple system frameworks do not have a Versions directory in them at
all.
Fixes the following traceback:
...
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/interpreter.py", line 3063, in func_dependency
d = self.dependency_impl(name, display_name, kwargs)
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/interpreter.py", line 3110, in dependency_impl
dep = dependencies.find_external_dependency(name, self.environment, kwargs)
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/dependencies/base.py", line 2142, in find_external_dependency
d = c()
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/dependencies/base.py", line 2004, in __init__
self.detect(name, paths)
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/dependencies/base.py", line 2035, in detect
incdir = self._get_framework_include_path(framework_path)
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/dependencies/base.py", line 2065, in _get_framework_include_path
self._get_framework_latest_version(path))
File "/Users/matt/Projects/cerbero/build/build-tools/lib/python3.7/site-packages/meson-0.51.999-py3.7.egg/mesonbuild/dependencies/base.py", line 2057, in _get_framework_latest_version
return 'Versions/{}/Headers'.format(sorted(versions)[-1]._s)
IndexError: list index out of range
There are two variables that CMake takes into account during
find_package() in cross-compiled environments, which are: CMAKE_SYSROOT
and CMAKE_FIND_ROOT_PATH. Those are used in cmFindCommon::RerootPaths()
function, which blindly prepends all search paths with those specified
via CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH.
Extend search paths by using CMAKE_SYSROOT and CMAKE_FIND_ROOT_PATH in a
similar way as CMake does, so we successfully find CMake packages
information in cross-compiled environments.
Dylan Baker
Daniel Mensinger
Stéphane Cerveau
Nirbheek Chauhan
Michael Hirsch, Ph.D
Ting-Wei Lan
Jonathan Perkin
Jussi Pakkanen
Xavier Claessens
Marvin Scholz
Wolfgang Stöggl
Aleksey Gurtovoy
Matthew Waters
David Seifert
Marcin Niestroj
Norbert Nemec