t.pic won't be defined. We can only hope it has been built with -fPIC.
Linker will complain otherwise any way.
t.extract_all_objects_recurse() won't be defined. We could support this
case by extracting the archive somewhere and pick object files.
* Have set() and set_quoted() of configuration object work with newlines.
set_quoted() makes the value into a double-quoted string, so let's
assume C-style string, in particular with newlines as "\n".
Also take care of remaining newlines in dump_conf_header(). C or nasm
macros expect single-line values so if the value was multi-line, we
would end up with broken syntax. Appending a backslash at each end of
line make them concat into a single line in both C and nasm format
(note: multi-line macros in nasm are actually possible apparently but
use another format not outputted by current meson code). Also note that
the replacement is done at the end only when dumping the conf as a
header because we cannot assume anything about the format when replacing
variables from an input file (in this case, it should be the dev
responsibility).
* Add unit tests for multiline set() and set_quoted().
Fortran: check for undeclared variables by forcing implicit none everywhere
C/C++: check for unused parameters and return types
removed unused variables from test cases
ci: do missing return and unused arg check with Github Actions
Previously if a user tried to pass a command line build
option that contained a '%' character the command line
parser assumed that there was string interpolation to be
done. As there is no sense in such a scenario no code
provides any input for the interpolation. This then leads to
a failure.
In this commit we specifically override the defaults in
ConfigParser and set interpolation to None, which disables
command line build option interpolation.
Fixes#6157
When a static library link_whole to a bunch of other static libraries,
we have to extract all their objects recursively. But that could
introduce duplicated objects. ar is dumb enough to allow this without
error, but once the resulting static library is linked into an
executable or shared library, the linker will complain about duplicated
symbols.
A build with a cross file should always be identified as a cross build, even if
the host and build machine are identical. This was the case in 0.50, regressed
in 0.51, and is fixed again in 0.52, so add a test case to ensure it doesn't
regress again.
Static libraries don't have PDB files. A PDB that would previously end
up installed alongside a static library belonged in fact to the dynamic
version of the same library built at the same time.
This was because the former minstall.Installer implementation, when
installing a file target, also blindly copied any *.pdb file it found
whose filename was matching the target. So, for example installing
foo.dll and foo.a would also install two copies of foo.pdb into both
bin/ and lib/, which doesn't seem like the right thing to do - foo.pdb
should only get installed with foo.dll.
Daniel Mensinger
Xavier Claessens
Marc
Michael Hirsch, Ph.D
Jehan
Michael Hirsch, Ph.D
Jussi Pakkanen
Paulo Neves
fchin
franczc
Wolfgang Stöggl
Aleksey Gurtovoy
James Hilliard
Ross Burton
Jakub Adam