Reuse the git helper for `meson wrap` and `meson subprojects` so we
don't need to maintain the same git-colors-on-windows workarounds in
multiple places.
`git submodule update --recursive` calls git clone recursively, and on
Windows it will undo the console mode we set in mlog and cause ANSI
colors to stop working. We could set it again only when we call that,
but we will definitely miss other instances where this could happen
in the future and regress.
pkgconf automatically prunes "system library paths" from its output. The
system library paths depend on the system toolchain. A common value on a
64-bit system is as follows:
/lib64:/usr/lib64:/usr/local/lib64
So, if -L/usr/lib64 appears in the Libs section, it will be pruned from
the output of pkg-config --libs.
The pc files generated for this test contain something like this:
libdir=/usr/lib
Libs: -L${libdir} ...
pkgconf may not consider /usr/lib to be a system library path, so it is
not pruned as the test expects. To work around this, override the
compiled-in list of paths via the PKG_CONFIG_SYSTEM_LIBRARY_PATH
environment variable.
Fixes: https://github.com/mesonbuild/meson/issues/6004
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
The pefile module is a CI dependency now, so we can use that instead
of objdump/dumpbin which greatly simplifies the test. Of course, this
module is also cross-platform so it will work if we add cross-win32 CI
at some point.
Make the 'framework/4 qt' test more flexible about what version of Qt is
expected to be present in the CI environment. Currently, this is
hard-coded as Qt5. We add an option to specify it so we can run this
test under CI with just Qt4 present.
fixes#6096.
Didn't use CMake because Curses is a real corner-case for CMake that
would require Curses-specific enhancements to Meson's CMake interface.
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.