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.
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.
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.
It is extremely common to need to know within a given dependency if
a given header, symbol, member, function, etc exists that cannot be
determined from the version number alone.
Without passing dependency objects to the various compiler/linker
checks and with many libraries headers/libraries being located in
their own subdirs of the standard prefix, the check for the library
would not find the header/function/symbol/etc.
This commit allows passing dependency objects to the compiler checks so
that the test program can be compiled/linked/run with the necessary
compilation and/or linking flags for that library.
Add support for passing a description to configuration data
setter methods via a 'description' kwarg. The description
string will be used when meson generates the entire configure
file without a template, autoconf-style.
These paths are now generated similar to
NinjaBackend.generate_single_compile where IncludeDirs create includes
of both the build directory path and the source directory path.
This also fixes a bug with include_directories, where the path string
supplied to the IncludeDirs initializer was used for the search path,
instead of the actual location to which it referred. Often, this was a
'.', and not a really useful path.
Patrick Griffis
Jussi Pakkanen
Nirbheek Chauhan
Thibault Saunier
Sam Thursfield
Sam Thursfield
Elliott Sales de Andrade
Guillaume Poirier-Morency
Matthew Waters
Tim-Philipp Müller
Thibault Saunier
Tim-Philipp Müller