We know exactly what type we need, since the interpreter function is
correctly typed and thinly wraps over this. But we didn't even get the
container type correct. :(
This would be either the value `kwargs['install']`, or `False`. There
isn't any case that `BuildTarget.need_install` handles that
`BuildTarget.install` doesn't handle, if we just initialized it
correctly. So, just set Target.install correctly in the super
initializer, and do away with need_install.
When running setup with `--profile-self` option,
there are currently no logs after "Found ninja...". However, there are
still some lengthy processes for generating targets and ninja.build.
This add more log entries, when profiling, only for the purpose of
displaying the timestamps of the different steps in ninja generation.
Jar has a very low set of overlap with other target types, including
that jar sources *must* be .java, and no other target allows .java
sources. As such, the difficulty in crafting a useful `build_target`
invocation that allows both `jar` and anything else is high, and the
usefulness is dubious. Just use `jar()` directly instead.
This depends on the changes to make all of the jar() specific keyword
arguments be handled by typed_kwargs so that the deprecation messages
are correct and consistent.
Also move it into the Jar class. This is an exclusive Jar keyword
argument, and is only used inside java paths, so there's no reason to
have this in all build targets.
This moves to a list of shared objects inside the type_checking module.
This is based on my experience of fully typing all of these functions
several times, and will make it easier to slowly land all of the changes
we want to make.
We already import a bunch of objects directly from ..build but don't use
them nearly as much as we can. This resulted both in longer lines and s
minor performance difference since python has to resolve the name
binding the long way. There's no reason not to rewrite these names to
use the direct imports.
Found while investigating the fact that Executable was imported but
never used. It's easier to just use it.
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
A linker mixin has to be able to align with the base linker it will be
used for, in order to reference super(). Since they weren't inherited,
calls to super() resulted in mypy errors, which we ignored, and casting.
Use the same trick we use for compilers, and make the linker inherit
from the base linker type when running under mypy, and from object at
runtime.
wine64 used to be the way to run a 64-bit wineserver. It was removed due
to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029536 despite
that bug report being about a bug in an unrelated symlink -- apparently
there's no recommended solution to starting a specific bitness of wine
on demand. The automagic `wine` I believe creates a wineprefix with
both, which is... probably not exactly efficient here? But whatever, not
worth fighting it. Just get this more or less working again.
The original point of specifying Optional was to default to None...
oops. The practical effect of this change is that the testsuite no
longer repeatedly logs "No tests defined." in between more meaningful
output.
They do not appear to have 15 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 20, so
choose one randomly and hope it doesn't keep changing value.
This brings the formatting more in line with other modules, in
particular the headers do not include the full function signature for
readability, keyword arguments are listed one-by-one, etc.
Do not run tests that use integers in versions with compiler that do
not support them.
Old versions of GDC supported plain integers in version and debug
strings but they are deprecated and GDC 13 hard errors on them.
These result in very large binaries when linked, and are not generally
useful. A user can turn them back on by passing `-C overflow-checks=yes`
manually via `-Drust_args` or the `RUSTFLAGS` environment variable
fixes: #11785
In order to pass a File object down into the compiler impl and compile
it, we cannot pass a string with the filename, and we cannot either pass
the File object as-is, since it relies on being given Environment
attributes to calculate the relative location. So we build a fresh File
object as an absolute path.
But the code to do this was totally broken. Instead of using the File
method to get an absolute path, we used one that expected to create
builddir-relative paths... and then gave it the absolute source dir as
the "relative path portion" prefix. This worked by accident as long as
it wasn't a built File, but if it was a built file then we intentionally
didn't include that prefix -- which was wrong anyway, since we need the
build directory!
Use the correct method to get an absolute path in all cases, and emit a
warning if it was a built file. This never worked. Sometimes it crashed,
sometimes it silently returned false.
Fixes#11983
GCC 12.3 and Clang 16 support -std flags for c++23/c++2b. The unreleased
GCC 14 and Clang 17 will support -std flags for c++26/c++2c.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
The c++23 mappings apply to current production compilers (GCC, Clang).
None of the production c++ compilers support c++26 flags yet, but this
mapping will be ready once they do.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
On windows, meson would mix posix and windows dir separators in the
computed PACKAGE_RELATIVE_PATH.
Here we force posix directory separator even on Windows. This matches
the CMake behavior and fixes interpretation of the resulting path.
Fixes#6955Fixes#9702
Some macos libraries use arm64e instead of arm64 as architecture. Due to the
string replace approach taken so far, we'd end up with aarch64e as
architecture, which the rest of meson doesn't know.
Move architecture mapping to map whole architecture names and add arm64e ->
aarch64 mapping.
This change doesn't touch the case for armv7[s], where we add arm, rather than
replace armv7[s], but it's certainly not in line with the other mappings.
Fixes: #9493
Co-authored-by: Tristan Partin <tristan@partin.io>
Eli Schwartz
Dylan Baker
George Sedov
Albert Tang
Charles Brunet
Xavier Claessens
kiwixz
Peter Hutterer
Jussi Pakkanen
Steven Noonan
Matthieu Rogez
Andres Freund