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>
- Do not hardcode terminal width of 100 chars, that breaks rendering on
smaller terminal. It already uses current console width by default.
- Disable progress bar when downloading from msubprojects because it
fetches multiple wraps in parallel.
- Scale unit when downloading e.g. MB/s.
- Do not display rate when it's not a download.
- Do not display time elapsed to simplify the rendering.
Checking the executable basename sort of works, at least for Windows,
since Windows always happens to use exactly this approach. However, the
official pyinstaller documentation suggests a very different approach:
https://pyinstaller.org/en/stable/runtime-information.html
This approach is more robust since it works on any OS, and in particular
it allows me to test the PyInstaller bundle functionality on Linux, even
though we don't officially distribute it as such.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
In commit 97a72a1c53 we started to allow
cmakedefine with 3 tokens, as cmake expects (unlike mesondefine). This
would silently start working even if the declared minimum version was
older than 0.54.1
It's actually Generic, and we should use Generic annotations to get the
correct result. This means that we don't have to assert or cast the
return type, because mypy just knowns
We shouldn't be hardcoding library dirs anyway. And we usually get this
from the compiler.
This function has been unused since its users were moved to use the
compiler method, in the following commits:
- a1a4f66e6d
- a3856be1d5
- 08224dafcb
After tracing all the way down to the bottom of this (or really, adding
annotations so mypy can) it turns out that passing file would just be
ignored at the end of the mlog call stack, so it should be removed
ctypes uses FFI, and surprisingly often people's Python installations
will be broken because ctypes is broken (e.g. the system libffi has been
updated and Python needs to be recompiled). That is not our fault, but
it does manifest as Meson failing to run. It turns out we aren't even
using it though. At least, pretty often.
We have two uses of ctypes, and both of them are for Windows. One of
them is already conditionally imported in the function that uses it, but
the other is imported at startup. Move this down into the invoking
function.
On non-Windows systems, it is now impossible for Meson to fail to run
when ctypes is broken, because we don't use it. Anecdotally, this issue
tends to come up on Linux systems primarily.
Fixes#11111Closes#11112
T.Sequence is a questionable concept. The idea is to hammer out generic,
maximally forgiving APIs that operate on protocols, which is a fancy way
of saying "I don't care if you use tuples or lists". This is rarely
needed, actually, and in exchange for this fancy behavior you get free
bugs.
Specifically, `somestr` is of type `T.Sequence[str]`, and also
`somestr[0]` is another string of type you guessed it. It's ~~turtles~~
strings all the way down.
It's worth noting that trying to code for "protocols" is a broken
concept if the contents have semantic meaning, e.g. it operates on
"the install tags of this object" rather than "an iterable that supports
efficient element access".
The other way to use T.Sequence is "I don't like that T.List is
invariant, but also I don't like that T.Tuple makes you specify exact
ordering". This sort of works. In fact it probably does work as long as
you don't allow str in your sequences, which of course everyone allows
anyway.
Use of Sequence has cute side effects, such as actually passing lists
around, knowing that you are going to get a list and knowing that you
need to pass it on as a list, and then having to re-allocate as
`list(mylist)` "because the type annotations says it could be a str or
tuple".
Except it cannot be a str, because if it is then the application is
fatally flawed and logic errors occur to disastrous end user effects,
and the type annotations:
- do not enforce their promises of annotating types
- fail to live up to "minimal runtime penalties" due to all the `list()`
Shun this broken concept, by hardening the type annotations. As it turns
out, we do not actually need any of this covariance or protocol-ism for
a list of strings! The whole attempt was a slow, buggy waste of time.
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
This finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
We have divergent implementations of loading a pickled *.dat file. The
Build class loader has a better error message. But the generic loader
handles TypeError and ModuleNotFoundError. Merge the implementations,
and use it for Build as well.
Fixes#11051
We would like to use the default value (the one python urged us not to
use), but without getting a warning for it. Luckily, we have the correct
value already, so we can pass it manually to avoid the complaint.
Move `detect_native_windows_arch()` to `mesonlib/universal.py` and
rename it to `windows_detect_native_arch()`
Use `IsWow64Process2()` to detect native architecture if available
Use native `vcvarsarm64.bat` to initialize vsenv if available
Those classes are used by wrapper scripts and we should not have to
import the rest of mesonlib, build.py, and all their dependencies for
that.
This renames mesonlib/ directory to utils/ and add a mesonlib.py module
that imports everything from utils/ to not have to change `import
mesonlib` everywhere. It allows to import utils.core without importing
the rest of mesonlib.
Type annotation, documentation string, and implementation were doing 3
different things. Change implementation to match type annotation which
makes the most sense because it match what get_target_sources() does.
All callers only use keys from the returned dictionary any way, but
that's going to change in next commits.
This does force a number of uses of `# pylint: disable` comments, but it
also finds a couple of useless global uses and one place (in the
previous commit) that an easy refactor removes the use of global. Global
is a code smell, so forcing adding a comment to disable helps force
developers to really consider if what they're doing is a good idea.
The `global` statement is only needed to assign to global variables, not
read or mutate them. So calling `global.mutate()` is fine, but not
`var = foo`, which would otherwise shadow `var`.
- Remove duplicated code in mdevenv.py
- Change the limit to 1024 instead of 2048 which is what has been
tested.
- Skip shortening if it is already short enough.
- Skip shortening with wine >= 6.4 which does not seems to have that
limitation any more.
- Downgrade exception to warning in the case WINEPATH cannot be
shortened under 1024 chars, it is possible that it will still work.
When need to catch exceptions just like we do in coredata.load() to
print proper error message instead of backtrace when user mix meson
versions.
This happens frequently when user has a newer version of meson installed
in their HOME and then "sudo meson install" uses the system version of
meson.
By default, meson will try to look for shared libraries first before
static ones. In the meson.build itself, one can use the static keyword
to control if a static library will be tried first but there's no simple
way for an end user performing a build to switch back and forth at will.
Let's cover this usecase by adding an option that allows a user to
specify if they want dependency lookups to try static or shared
libraries first. The writer of the meson.build can manually specify the
static keyword where appropriate which will override the value of this
option.
It is always used as an immutable view so there is no point in doing
copies. However, mypy insist it must implement the same APIs as
Dict[OptionKey, UserOption[Any]] so keep faking it.
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
There's no reason it needs a concrete list, any iterable is fine. This
does mean that we need to explicitly check for `str | bytes` in the
listify pass, as `str` and `bytes` are both iterable.
Andres Freund
Tristan Partin
Eli Schwartz
Xavier Claessens
Josh Soref
Dylan Baker
X512
L. E. Segovia
Marvin Scholz
GustavoLCR
Zhangyuan Nie
Dudemanguy
Sergey Fedorov
barracuda156