Clang's resource files, e.g. /usr/share/clang/clang++.cfg, can be used to bump the default standard level across the system.
However due to llvm/llvm-project#61641 `clang++ -std=c++17 -E -dM -` doesn't work. The workaround is to pass the language explicitly.
4ad792e158 fixed the issue by passing the language explicitly, but started passing the `-cpp` flag, which Clang doesn't support.
Basically Clang would always fallback to the second detection attempt as a result. Remove the unsupported flag and the above scenarios works now too. 🙂
See-also: https://github.com/llvm/llvm-project/issues/61641
Fixes: 4ad792e158
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
_get_gnu_compiler_defines and _get_clang_compiler_defines were broken
by not defining the language they used.
Neither GCC nor Clang infer the language based on the driver name which means
`self.defines` isn't populated correctly in compilers/cpp.py.
e.g.
```
$ echo "" | g++ -E -dM - | grep -i cplus
$ echo "" | g++ -x c++ -E -dM - | grep -i cplus
#define __cplusplus 201703L
```
Fix that by passing '-cpp -x LANGUAGE' as a first pass. If it fails, try
again without '-cpp -x LANGUAGE' as before, as its portability isn't
certain. We do '-cpp' because during testing, I found Fortran needs this,
although per below, I had to drop Fortran in the end and leave it to the
fallback (existing) path.
Without this change, a63739d394 is only
partially effective. It works if the system has injected Clang options
via /etc/clang configuration files, but not by e.g. patching the driver
(or for GCC there too).
Unfortunately, we have to wimp out for Fortran and fallback to the
old method because you need the language standard (e.g. -x f95).
Make the debug & error message strings consistent between the GCC and Clang probes.
Copy-paste error. Here, we're scraping pre-processor tokens, not checking
for the compiler type.
GCC only has very limited support for Objective-C and doesn't support
any of the modern features, so whenever Clang is available, it should be
used instead. Essentially, the only reason to ever use GCC for
Objective-C is that Clang simply does not support the target system.
If nasm is not defined in cross file binaries we can fallback to build
machine nasm.
When cross compiling C code we need a different gcc binary for native
and cross targets, e.g. `gcc` and `x86_64-w64-mingw32-gcc`. But when
cross compiling NASM code the compiler is the same, it is the source
code that has to be made for the target platform. We can thus use nasm
from build machine's PATH to cross compile for Windows on Linux for
example. The difference is the arguments Meson will pass when invoking
nasm e.g. `-fwin64`. That is already handled by NasmCompiler class.
When C6000 support was added in #12246, TI compilers were given the correct version argument.
This broke the previous check which relied on an error being thrown by the compiler.
Places where compiler needs it already have access to Environment object
and can use it directly.
This fixes mypy complaining that not all compilers have self.exe_wrapper
in run() method that got moved to base class.
Currently both print `Detecting linker via`, which can be confusing.
Clarifying this by printing "archiver" instead of "linker" for the
static linker/archiver
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
Cython historically, when asked to print the version and exit
successfully, would do so on stderr, which is weird and inconsistent.
Recently, it fixed this UX bug by printing on stdout instead:
https://github.com/cython/cython/issues/5504
This then broke meson detection because we assumed it was on stderr due
to historically being there:
https://github.com/scipy/scipy/issues/18865
Cython is right, and shouldn't have to revert this reasonable change for
backwards compatibility. Instead, check both.
This saves on a 1500-line import at startup and may be skipped entirely
if no compiled languages are used. In exchange, we move the
implementation to a new file that is imported instead.
Followup to commit ab20eb5bbc.
The version output scraping for identifying strings checked for "IFORT"
in parentheses after the executable name, which is probably a mistake by
Intel. Current versions of ifx have "IFX" in parentheses there.
Detect both.
Fixes#11873
By default clippy-driver will report its own version, which is not very
useful to check the toolchain version. Instead make sure to extract the
actual toolchain version here.
clang --version can yield a string like below when its installed into
such a directory
clang version 14.0.0 (https://github.com/llvm/llvm-project 3f43d803382d57e3fc010ca19833077d1023e9c9)
Target: aarch64-yoe-linux
Thread model: posix
InstalledDir: /mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux/gnome-text-editor/42.0-r0/recipe-sysroot-native/usr/bin/aarch64-yoe-linux
as you can see InstallDir has 'xt-' subtring and this trips the check to
guess gcc
if 'Free Software Foundation' in out or 'xt-' in out:
Therefore, check if compiler output starts with xt- then assume
it to be gcc
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Raul Tambre
Andrew McNulty
spaette
Zihua Wu
Jussi Pakkanen
slimeuniverse
Jonathan Schleifer
H. Vetinari
Sam James
Axel Ricard
Xavier Claessens
William D. Jones
Will Toohey
Petr Machacek
Charles Brunet
dragonmux
Dylan Baker
Filipe Laíns
Eli Schwartz
Alyssa Ross
Volker Weißmann
Nomura
Sebastian Dröge
Josh Soref
Khem Raj
L. E. Segovia
Kleis Auke Wolthuizen
Robert Cohn