In qemu, minikconf generates a depfile that meson could use to
automatically reconfigure on dependency change.
Note: someone clever can perhaps find a way to express this with a
ninja rule & depfile=. I didn't manage, so I wrote a simple depfile
parser.
Since commit 38a658214 ("configure_file: Support taking values from a
dict" #4236), configuration_data() and configure_file()'s
configuration kwarg can take a dict. Add missing version checks.
This is similar to what we currently do for scan-build except there is
no environment variable to choose a specific clang-format to run. If an
environment variable is needed for better control, we can add it later.
Both scan-build and llvm-config need the same list of LLVM version
suffixes. It is better to keep the list at a common place instead of
having several copies in different files, which is likely to become
out-of-sync when the list is updated.
Versioning of executables is not related to the operating system kernel.
It is possible for a Linux distribution to support multiple versions of
LLVM in a way similar to FreeBSD. For example, on Debian, you can use
'apt install clang-tools-7' to install the versioned 'scan-build-7'
executable without bringing the unversioned 'scan-build' into the
environment. Therefore, we should not skip the version list on Linux.
It also makes it consistent with the behavior of llvm dependency, which
does not change the search list depending on the operating system.
This commit also fixes the version suffix for Debian. Debian stops using
the minor version number on the executable after version 7, so it should
be 'scan-build-7', not 'scan-build-7.0'.
This is a follow-up of https://github.com/mesonbuild/meson/pull/5918.
According to http://testanything.org/tap-specification.html
"Any output line that is not a version, a plan, a test line, a
diagnostic or a bail out is considered an “unknown” line. A TAP parser
is required to not consider an unknown line as an error but may
optionally choose to capture said line and hand it to the test
harness, which may have custom behavior attached [...] TAP::Harness
reports TAP syntax errors at the end of a test run".
(glib gtest can generate empty lines)
The main library must come before extra libraries, because they are
likely to be dependencies of the main library that get promoted from
private to public. This was causing static link issues with glib-2.0.pc.
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
Solaris puts 32-bit libraries in the main /lib & /usr/lib directories
and 64-bit libraries in platform specific subdirectories.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Solaris doesn't ship static libraries, so the test can't rely on libz.a
existing on Solaris.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the Python binary that we find doesn't return valid JSON when asked to run a
small script, show the command being ran and stdout/stderr in meson-log.txt.
Fixes: #5914
Xavier Claessens
Marc-André Lureau
Olexa Bilaniuk
Jussi Pakkanen
Christoph Weiss
Ting-Wei Lan
Dylan Baker
Andrew Conrad
Andrei Alexeyev
Aleksey Gurtovoy
Daniel Mensinger
Nathan Rossi
David Cantrell
Zbigniew Jędrzejewski-Szmek
Patrick Griffis
Khairul Azhar Kasmiran
Jehan
jimbo1qaz
Gabriel Ganne
Alan Coopersmith
Ross Burton