We cover every case as if/elif/elif. mypy can handle this fine, but
pylint doesn't do control flow or type checking and thinks in the
missing else case, the variable might not be defined.
For mypy as well, doing this instance check is unnecessary as it can be
inferred. So just micro-optimize the check and allow pylint to safely
analyze the logic.
xtools is in use on Gentoo Prefix x86_64 and ppc based Darwin installs.
Pick it up as a valid linker.
Since xtools is answering with a version to --version, as opposed to
ld64, detection of xtools in the ld64 handling block is not possible,
since --version already succeeded.
Bug: https://bugs.gentoo.org/868516
Bug: https://github.com/mesonbuild/meson/issues/10805
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
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
Previously macos reported "ld: unknown option: --version" when being passed
--version, but now sometimes it reports in plural, albeit without an obvious
pattern when. To handle that, simply just check for the prefix without the :
Fixes: https://github.com/mesonbuild/meson/issues/12552
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/
```
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.
Currently we invoke it with lang_args only, which is wrong and probably
useless.
Fixes misdetecting the linker when overridden as -fuse-ld, which led to
Meson trying to pass incompatible flags, outright failing if CFLAGS
contained flags that only work with a non-default linker, or in the most
benevolent case, having the status log report the wrong linker.
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.
mingw GCC using ld.bfd emits diagnostics that include
"-plugin-opt=-pass-through=-lmoldname" and this triggers a match for
mold when it should not.
Instead, always check the very beginning of the output for the linker
id. This is pretty consistent:
- it is always on stdout
- GCC may put additional things on stderr we don't care about
- swift is bizarre and on some OSes redirects the linker stdout to
swiftc's stderr, but it will still be the only stderr; we didn't even
check stderr at all until commit 712cbe0568
For gold/bfd linkers, the linker id is always the *second* word, after
the legally mandated "GNU" we already check for.
[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>
These are only used for type checking, so don't bother importing them at
runtime.
Generally add future annotations at the same time, to make sure that
existing uses of these imports don't need to be quoted.
e7c972b606
added PACKAGE_VENDOR to lld, causing the -v output to start with "Homebrew LLD"
rather than just "LLD". Meson no longer detects it and fails the
test_ld_environment_variable_lld unit test.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Eli Schwartz
William Toohey
L. E. Segovia
Fabian Groffen
Dylan Baker
Andres Freund
Eli Schwartz
Jussi Pakkanen
Josh Soref
jack
David Robillard
Fini Jastrow
Paolo Bonzini
Daniel Mensinger