* add support for wrap of mercurial repo, and a test with a clone of the sample subproject used for the git test into a mercuriel repo.
* Added myself to author list, and switched the URL of the sample subproject in the wrap file to one under the control of the project's maintainers.
This is the first step in making Vala support have feature-parity with
C/C++ support. Vala and Vapi sources generated with Generators and
CustomTargets are no longer ignored. Dependencies are setup properly and
they are added to the commandline.
Pre-calculate the output directory for GeneratedList and CustomTarget so
we can directly use the same code for both while compiling C/C++ files
and headers.
There is no reason to have separate branches for GeneratedList and
CustomTarget since both can be used in almost exactly the same way for
generating sources.
This is going to used next for adding generated sources support to Vala.
This isn't useful yet because we currently only have dependencies for
C/C++ targets (the rest all use link deps), but we will need this for
Vala, Rust, and more.
get_filename() made no sense for CustomTarget since it can have multiple
outputs. Also use get_outputs() for GeneratedList since it has the same
meaning and remove unused set_generated().
As a side-effect, we now install all the outputs of a CustomTarget.
If a fallback dependency is not found just return None. The
caller can then raise the exception it already has if
required=True, or just continue on if required=False.
This is done by adding a new compiler method called 'no_warn_args' which
returns the argument(s) required for the compiler to emit no warnings
for that compilation.
This take care of not disabling warnings for C code compiled into the
BuildTarget. Also includes tests for ensuring all this.
https://github.com/mesonbuild/meson/issues/864
In the case the main project set a subproject for a dependency another
subprojects uses, that other subproject should rather use the first
subproject rather that using native dependency.
For example in gst-all we set all GStreamer modules as subprojects
and, gst-plugins-base is set after gstreamer core, and
we want gst-plugins-base to always use GStreamer core from the subproject
and not the possibly avalaible native one.
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
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.
Patrick Griffis
AlexandreFoley
Jussi Pakkanen
Nirbheek Chauhan
Hemmo Nieminen
Scott D Phillips
Guillaume Poirier-Morency
Thibault Saunier
Sam Thursfield
Elliott Sales de Andrade
Igor Gnatenko
Emanuele Aina