Instead of using a whitelist, use a blacklist. Also print a more useful
error if the regex fails to match.
Use an underscore in the gir test to trigger this.
Fixes#436
Since Vala require 'glib-2.0' and 'gobject-2.0' dependencies, it's
better to fail at 'valac' step with meaningful error.
Add missing 'gobject-2.0' dependency on the mixed source test case.
Can only test this by checking the compiler id, but that's good enough.
Disabling so we can get #995 in which will help keep the VS backend in
a better state w.r.t. other PRs.
I've opened #1004 to track this in the meantime.
The code generated manually with manygen.py must use the same CRT
compiler arguments as the final executable itself or we get an error
during linking:
MSVCRTD.lib(_chandler4gs_.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in function __except_handler4
depuser.exe : fatal error LNK1120: 1 unresolved externals
The pkg-config version shipped with MinGW is too old, and the test is
sufficiently covered on Linux, so just skip it on Windows. We anyway do
not run the other pkg-config tests on Windows.
Need to pass -fpermissive to force C++ compilers to only warn about our
non-conformant code that tests for a symbol being defined.
Also do a simple #ifdef check first in has_header_symbol to allow
arbitrary macros to be detected which would not have been detected
earlier. This follows what AC_CHECK_DECL does.
Closes#958
All assignments in meson should be by value, so mutable objects
(i.e. environment() and configuration_data()) should be copied
automatically on assignment.
Fixes#831.
If first checking for a dependency as not-required, and then later
checking for the same dependency again as required, we would not
error out saying the dependency is missing, but just silently
re-use the cached dependency object from the first check and then
likely fail at build time if the dependency is not actually there.
With test case.
Fixes#964.
Not only does extract_all_objects() now work properly again,
extract_objects() also works if you specify a subset of sources all of
which have been compiled into a single unified object.
So, for instance, this allows you to extract all the objects
corresponding to the C sources compiled into a target consisting of
C and C++ sources.
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.