And remove the InternalDependencyHolder class.
In some cases we need to know the type of dependency we are
dealing with. For example in GStreamer if the dependency
is not an internal one, then we need to get some env var
from pkg-config to know where to find some plugins necessary
to run some tests.
This commit adds a 'dependencies' keyword to the
gnome.compile_resources() function, which allows your resource blob
to depend on files generated at build-time from custom_target() or
configure_file() targets.
My current use case for this is source data that gets processed with Gettext
translation tools before being compiled into the resource blob.
This feature only works with GLib version 2.48.2 and above. So the
compile_resources() function now detects GLib version and raises an
error if the version of GLib being used is too old.
The compile_resources() test case is now split into two, so that the
existing one can continue to run on systems with old GLib versions (such
as Ubuntu Xenial, which the automated tests on travisci.org use), but
where new enough GLib is available we also test generating gresource
content.
The existing warning about glib-compile-resources is now only printed
if GLib version is older than 2.50.0 because
<https://bugzilla.gnome.org/show_bug.cgi?id=745754> is fixed in the
2.50.0 release.
Reduces duplicated code, and also use universal_newlines=True which
avoids having to decode the bytes output to string.
We mostly need this so we can pass the *current* process environment to
pkg-config which might've changed since the module was imported. Without
this, subprocess.Popen invokes pkg-config with a stale environment (used
in the unittest added later)
Sometimes people want the library to start with 'lib' everywhere, which
is achieved by setting name_prefix to '' and the target name to
'libfoo'. In that case, try to get the pkg-config '-lfoo' arg right.
Also, don't warn about anything on Windows
Fixes https://github.com/mesonbuild/meson/issues/889
There is no reason to not always do this. Without this, we end up with
a relative path to meson.py in build.ninja files when meson.py is
launched using subprocess.Popen and friends from the meson source root.
This was causing the unittests to intermittently fail when regen was
getting invoked by the pic test. Funnily enough, this only happened when
run via ./run_tests.py because __file__ was 'run_unittests.py' in that
(as opposed to './run_unittests.py') case which made
os.path.dirname(__file__) be '', and the os.path.split test in meson.py
thought that meson.py was invoked via PATH.
In Fedora we don't care about prefix, we want to ensure that libdir
is /usr/lib64, localedir is /usr/share/locale, and cetera.
Additionally, we don't need to ensure that prefix is absolute as we
check it in main.
Fixes: cc19bf0f45 ("Move option validation in objects rather than doing it only in the conf script.")
Closes: https://github.com/mesonbuild/meson/issues/869
Signed-off-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
When installing Meson, distutils may choose to put shim scripts in the
`PATH` that only set up the egg requirements before launching the real
`meson.py` contained in the egg.
This means that `__file__` points to the real `meson.py` file, but
launching it directly is doomed to fail as it's missing the metadata
contained in the shim to set up the path egg, resulting in errors when
trying to import the `mesonbuild` module.
A similar issue affects Meson when installed as a zipapp, with the
current code going great lengths to figure out how to relaunch itself.
Using `argv[0]` avoids these issues as it gives us the way the current
executable has been launched, so we are pretty much guaranteed that
using it will create another instance of the same executable. We only
need to resolve relative paths as the current working directory may
get changed before re-launching the script, and using `realpath()` for
that saves us the trouble of manually resolving links and getting caught
in endless loops.
This also mean that `meson_script_file` no longer necessarily point to a
absolute file, so rename it to `_launcher` which hopefully would be less
prone to inducing false assumptions.
With C/C++, on Windows you don't need to pass any arguments for a static
library to be PIC. On UNIX platforms you need to pass -fPIC.
Other languages such as D have compiler-specific PIC arguments required
for PIC support in static libraries on UNIX platforms.
This kwarg allows people to specify which static libraries should be
built with PIC support. This is usually used for static libraries that
will be linked into shared libraries.
Thibault Saunier
Sam Thursfield
Sam Thursfield
Jussi Pakkanen
Elliott Sales de Andrade
Nirbheek Chauhan
Igor Gnatenko
Patrick Griffis
Franz Zapata
Guillaume Poirier-Morency
Emanuele Aina