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.
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)
While adding link args for external deps, sometimes different
libraries come from different prefixes, and an older version of the
same library might be present in other prefixes and we don't want to
accidentally pick that up.
For example:
/usr/local/lib/libglib-2.0.so
/usr/local/lib/pkgconfig/glib-2.0.pc
/usr/local/lib/libz.so
/usr/local/lib/pkgconfig/zlib.pc
/home/mesonuser/.local/lib/libglib-2.0.so
/home/mesonuser/.local/lib/pkgconfig/glib-2.0.pc
PKG_CONFIG_PATH="/home/mesonuser/.local/lib/pkgconfig/:/usr/local/lib/pkgconfig/"
If a target uses `dependencies : [glib_dep, zlib_dep]`, it will end up
using /usr/local/lib/libglib-2.0.so instead of
/home/mesonuser/.local/lib/libglib-2.0.so despite using the pkg-config
file in /home/mesonuser/.local/lib/pkgconfig because we reorder the -L
flag and separate it from the -l flag.
With this change, external link arguments will be added to the
compiler list without de-dup or reordering.
Closes https://github.com/mesonbuild/meson/issues/1718
- Adds a `crate_type` kwarg to library targets, allowing the different
types of Rust [linkage][1].
- Shared libraries use the `dylib` crate type by default, but can also
be `cdylib`
- Static libraries use the `rlib` crate type by default, but can also
be `staticlib`
- If any Rust target has shared library dependencies, add the
appropriate linker arguments, including rpath for the sysroot of the
Rust compiler
[1]: https://doc.rust-lang.org/reference/linkage.html
This is more reliable, and more accurate. For instance, this means
arguments in commands aren't surrounded by `'` on Linux unless that
is actually needed by that specific argument.
There is no equivalent helper for Windows, so we keep the old
behaviour for that.
Note that gui_app: is currently ignored when using the ninja backend with VS
compilers, so I guess you get the default linker behaviour, which the
documentation says is guessing the subsystem depending on if a main or
WinMain symbol exists...
Module definition files may be useful when building with gcc on Windows also
(e.g. if the existing build uses them, if exports are aliased, if we were
retro enough to export by ordinal, etc.)
Add the .def file to the link command line when using gcc on Windows
Run the appropriate windows tests irrespective of compiler.
Thibault Saunier
Jussi Pakkanen
Nirbheek Chauhan
Elliott Sales de Andrade
nyorain
Ben
Gabríel Arthúr Pétursson
Sam Thursfield
Adam C. Foltzer
Patrick Griffis
Jon Turney
Goncalo Carvalho
Guillaume Poirier-Morency
Alistair Thomas
Bálint Aradi
Rob Doolittle
Ole André Vadla Ravnås
Bálint Aradi