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>
This used to be fine, until imports were removed from this file. Now a
function annotated as T.NoReturn doesn't actually tell mypy that it
cannot return, though, so we manually do it.
We no longer need these upfront at all, since we now import the ones we
need for the language we are detecting, at the time of actual detection.
This avoids importing 28 files, consisting of just under 9,000 lines of
code, at interpreter startup. Now, it is only imported depending on
which languages are invoked by add_languages, which may not even be
anything. And even if we do end up importing a fair chunk of it for
C/C++ projects, spreading the import cost around the interpreter runtime
helps responsiveness.
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
Instead of comparing against specific compiler classes, check the
logical compiler id or language etc.
In a couple cases, we seem to be missing a couple things by being a bit
too strict about the exact class type.
If this command fails, for example when CXX is something not generic
enough to be a valid universal compiler command (clang -std=c++11
perhaps), we end up with two problems:
- it's impossible to figure out what Meson ran to get that error
- the error report isn't clear on what is stdout and what is stderr, or
even that that is what the message is about.
```
meson.build:1:0: ERROR: Unable to get clang pre-processor defines:
error: invalid argument '-std=c++11' not allowed with 'C'
```
What's C doing there and why is Meson talking about it? Answer: that's
compiler stdout. Say so.
We do something similar when running get_compiler() method checks from
the DSL. This ensures that if errors happen, the log file we tell people
to check actually works.
Transpilers need to run on the build machine in order to generate their
output, which can then be taken by a cross-compiler to create the final
output.
[why]
Support for the relatively new mold linker is missing. If someone wants
to use mold as linker `LDFLAGS="-B/path/to/mold"` has to be added instead
of the usual `CC_LD=mold meson ...` or `CXX_LD=mold meson ...`.
[how]
Allow `mold' as linker for clang and newer GCC versions (that versions
that have support).
The error message can be a bit off, because it is generic for all GNU
like compilers, but I guess that is ok. (i.e. 'mold' is not listed as
possible linker, even if it would be possible for the given compiler.)
[note]
GCC Version 12.0.1 is not sufficient to say `mold` is supported. The
expected release with support will be 12.1.0.
On the other hand people that use the un-released 12.0.1 will probably
have built it from trunk. Allowing 12.0.1 is helping bleeding edge
developers to use mold in Meson already now.
Fixes: #9072
Signed-off-by: Fini Jastrow <ulf.fini.jastrow@desy.de>
Dylan Baker