Detect scan-build the same way when trying to launch it and when
generating the target.
The detection method is:
1. look within SCANBUILD env variable
2. shutil.which('scan-build')
3. *on non-linux platforms only*: go through all the possible
name candidates and test them individually.
The third step is added following this comment
https://github.com/mesonbuild/meson/pull/5857#issuecomment-528305788
However, going through a list of all the possible candidates is neither
easily maintainable nor performant, and is therefore skipped on
platforms that should not require such a step (currently, only Linux
platforms).
This is a follow-up to the issue raised by @lantw44 during PR:
https://github.com/mesonbuild/meson/pull/5857
* Do not strip static archives
Stripping static archives without more fine-grained options (e.g. `-g`)
leads to failures such as
ld: libfoo.a: error adding symbols: archive has no index; run ranlib to add one
because GNU strip removes *every* symbol in a static archive by default.
Given that static archives are not final build artifacts (unlike
executables and shared libraries), stripping them gains little and only
causes more edge case failures.
* Gentoo's portage only strips debug information:
86f211e3a5/bin/estrip (L322)
* Fedora also only strips debug information:
e9c13c6565/scripts/brp-strip-static-archive (L18)
* Debian also only does some very light stripping:
72ed1d3261/dh_strip (L374)Fixes#4138
* Add test case for static archive stripping
as what was done with clang-format, test the presence of the tool before
generating a dedicated target. Pass silently if scan-build is not found.
Signed-off-by: Gabriel Ganne <gabriel.ganne@mindmaze.ch>
* backends/vs: Only set platform_toolset if it isn't already set
* interpreter: set backend up after the compiler
Otherwise we won't be able to check which VS toolchain to use.
* docs/using-visual-studio: wrap lines
* docs: recommend the py launcher instead of python3 for windows
* set backend.environment when building a dummy version
* backends/vs: Add support for clang-cl with vs2017 and vs2019 backends
* backends/vs: Add support for ICL (19.x) with vs2015 and vs2017 backends
"exe.is_cross and exe.needs_exe_wrapper" is the same condition under which
meson chooses whether to include the exe_wrapper. meson_exe has an assertion
for that, but now that meson_exe does not need anymore exe.is_cross,
we can simplify the code if we just "trust" meson to do the right thing.
Remove both fields from ExecutableSerialisation and just test the presence
of the wrapper, and also remove the executable basename which is only
used to "beautify" an assertion failure.
Move the magic to execute jar and .exe files from "meson --internal exe"
to the backend, so that "ninja -v" shows more clearly what is happening.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If meson_exe is only being used to capture the output of the command,
we can skip going through a pickled ExecutableSerialization object.
This makes "ninja -v" output more useful.
Return the command line from serialize_executable, which is then
renamed to as_meson_exe_cmdline. This avoids repeating code that
is common to custom targets and generators.
There are two problems with this:
- It has false positives when the code that trips it is conditional and
no run on cross.
- It confuses users who never wrote any `native` flags and don't care
about cross.
Fixes#5509
- AttributeError: 'ValaCompiler' object has no attribute 'get_program_dirs'
Fixed by adding a `get_program_dirs()` function to the base Compiler
class, to match `get_library_dirs()`
- KeyError: 'vala_COMPILER'
Fixed by creating the Vala compile rules for all machines, not just
the build machine.
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
when we are generating the include directories for a build target, then
we are iterating over all include directories, check if they are . or ..
and if not, generate a compile args object for it. However, the join
calls and the generation of the compile object is quite expensive, if we
cache the results of this, then we can _generate_single_compile from 60%
to roughly 50%.
the problem here is, that get_custom_target_provided_libraries iterated
over all generated sources of a target. In each output we check if this
is a library or not. In projects like EFL we have added a lot of
generated target to many different targets, so the iterating of the
output is rather consistent, with this commit we drop from 19% of the
time spending in get_custom_target_provided_libraries down to 3.51%.
Switch from build.compiler to environment.coredata.compiler and likewise
from build.cross_compiler to environment.coredata.cross_compiler in
backends. (Only seems to be actually used in ninja backend).
This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
Also, we should at some point decide whether we're going to use American
spelling (serialize/serialization) or British (serialise/serialisation)
because we have both, and both is always worse than one or the other.
Currently C++ inherits C, which can lead to diamond problems. By pulling
the code out into a standalone mixin class that the C, C++, ObjC, and
Objc++ compilers can inherit and override as necessary we remove one
source of diamonding. I've chosen to split this out into it's own file
as the CLikeCompiler class is over 1000 lines by itself. This also
breaks the VisualStudio derived classes inheriting from each other, to
avoid the same C -> CPP inheritance problems. This is all one giant
patch because there just isn't a clean way to separate this.
I've done the same for Fortran since it effectively inherits the
CCompiler (I say effectively because was it actually did was gross
beyond explanation), it's probably not correct, but it seems to work for
now. There really is a lot of layering violation going on in the
Compilers, and a really good scrubbing would do this code a lot of good.
Gabriel Ganne
David Seifert
Aleksey Gurtovoy
Michael Hirsch, Ph.D
Gabriel Ganne
Peter Hutterer
Dylan Baker
Jussi Pakkanen
Rachel Mant
Nirbheek Chauhan
Paolo Bonzini
Xavier Claessens
John Ericson
James Westman
Marcel Hollerbach
filippocrocchini
Jon Turney
John Ericson
TheQwertiest