Currently meson only considers what compiler/linker were used by a
Target's immediate sources or objects, not the sources of libraries it's
linked with by the link_with and link_while keywords. This means that if
given 3 libraries: libA which is C++, libB which is C, and libC which is
also C, and libC links with libB which links with libA then linking libC
will be attempted with the C linker, and will fail.
This patch corrects that by adding the compilers used by sub libraries
to the collection of compilers considered by meson when picking a
linker.
This adds a new process_compilers_late method to the BuildTarget class,
which is evaluated after process_kwargs is called. This is needed
because some D options need to be evaluated after compilers are
selected, while for C-like languages we need to check the link* targets
for language requirements, and link* targets are passed by kwargs.
This implementation is recursive, since each Target adds it's parent's
dependencies.
Otherwise we might end up with wrapper holders in the Build object and
pickling will then fail, defeating the purpose of the holder objects.
Closes https://github.com/mesonbuild/meson/issues/2211
In version 3.6.0, clang added -Wignored-optimization-argument. Without
setting this flag to -Werror, "ignored optimization arguments" such as
(for example) -fpeel-loops, are accepted but warned about, leading to
noisy builds if meson thinks the flag is supported.
See also #755
We prefer pkg-config files, though only OpenMPI supplies them.
Otherwise, check environment variables and search for wrappers and ask
them for what to do.
Currently if a target uses link_whole, and one of those archives is a
C++, but the files for the target are C linking will fail when the C
linker attempts to link the C++ files. This patches add
link_whole_targets to the list of languages in the target so the correct
linker will be selected.
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)
Luke Shumaker
Niklas Claesson
Dylan Baker
Nirbheek Chauhan
Martin Blanchard
Hristo Venev
Daniel Stone
Jussi Pakkanen
Peter Harris
Elliott Sales de Andrade
Alan Coopersmith
Patrick Griffis
Rico Tzschichholz
Jon Turney
FredericHamel