Fix an error in the windows vulkan_sdk library finding.
Also don't fail the vulkan test only because no vulkan
driver is installed (should fix the travis error).
Rework the vulkan module:
- adopt the VULKAN_SDK paths for its linux version
- add sanity tests for the VULKAN_SDK path
- add guessing as last fallback, needed on linux systems
on which no vulkan pkgconfig is installed [ubuntu atm]
- restructure exception handling/branching
Not tested on windows yet.
Precompiled headers should generally be compiled with the same flags as
the sources that will include the header. Some deviations are safe,
however, most will cause the compiler to reject the precompiled header
or possibly lead to compiler crashes.
Otherwise, when you have a static helper library written in Vala
that you want to `link_whole` into a shared library you have to
manually add the .vapi file as a source.
The glib-genmarshal tool was rewritten in GLib 2.53.3, and now supports
more command line arguments, such as:
"--pragma-once": emits a "#pragma once" instead of the old header
guards when generating the header file
"--prototypes": emits the marshallers prototype when generating the
source file
"-D,-U": defines and undefines pre-processor symbols
"--include-header": emits an "#include" directive when generating the
source file for the specified header file
Meson should take advantage of these new options, as they can be used to
replace most of the ad hoc build rules that projects are currently using
to implement the same thing.
Instead of mapping each option to a named argument, I used the same
approach as the compile_resources() and generate_gir() methods; the
genmarshal() method now has an 'extra_args' argument that can be used to
pass extra arguments to the glib-genmarshal tool.
In addition to filtering libs out while generating the command-line, we
must also filter them out in find_library() otherwise these libs will be
detected as "found" on Windows with MSVC.
Closes https://github.com/mesonbuild/meson/issues/1509
This commit amends 04a2e6de making
linker.get_std_shared_lib_link_args() always return -shared for
SharedLibrary(es) instead of -bundle. SharedModule(s) get linked with
linker.get_std_shared_module_link_args() which already correctly returns
-bundle.
Before this change -bundle and -install_name ended up being emitted
for Objective-C shared libraries, which caused a linking error.
When dealing with the SharedLibrary or StaticLibrary include
directories, we where not taking into acount that path are relative to
the source tree. With proper helper, this works now. This fixues issue
where the gir may be generated bug from headers found in the prefix.
Add a boolean 'implib' kwarg to executable(). If true, it is permitted to
use the returned build target object in link_with:
On platforms where this makes sense (e.g. Windows), an implib is generated
for the executable and used when linking. Otherwise, it has no effect.
(Rather than checking if it is a StaticLibrary or SharedLibary, BuildTarget
subclasses gain the is_linkable_target method to test if they can appear in
link_with:)
Also install any executable implib in a similar way to a shared library
implib, i.e. placing the implib in the appropriate place
Add tests of:
- a shared_module containing a reference to a symbol which is known (at link
time) to be provided by the executable
- trying to link with non-implib executables (should fail)
- installing the implib
(This last one needs a little enhancement of the installed file checking as
this is the first install test we have which needs to work with either
MSVC-style or GCC-style implib filenames)
Patrick Griffis
nyorain
Jussi Pakkanen
Nirbheek Chauhan
Luca Mattiello
Rico Tzschichholz
Gabríel Arthúr Pétursson
Sam Thursfield
Emmanuele Bassi
Dima Krasner
Nirbheek Chauhan
Igor Gnatenko
Adam C. Foltzer
Alessandro Decina
Karl-Philipp Richter
Nicolas Dufresne
Hagai
Christoph Reiter
Jon Turney