| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
At least, if you tried to use it when passing an install_dir. Because
T.Sequence is horrible and we should never use it, and the annotations
are a lie that produces bugs.
So, fix the annotations on CustomTarget to never allow this to happen
again, and also fix the function too. Move some definitions elsewhere
inline to satisfy the linter.
Fixes #11157
|
|
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.
|
|
There are two problems here: a typing problem, and an algorithm problem.
We expect it to always be passed to CustomTarget() as a list, but we ran
list() on it, which became horribly mangled if you violated the types
and passed a string instead. This caused weird*er* errors and didn't
even do anything. We want to do all validation in the interpreter,
anyway, and make the build level dumb.
Meanwhile we type it as accepting a T.Sequence, which technically
permits... a string, actually. This isn't intentional; the point of
using T.Sequence is out of a misguided idea that APIs are supposed to be
"technically correct" by allowing "anything that fulfills an interface",
which is a flawed concept because we aren't using interfaces here, and
also because "technically string fulfills the same interface as a list,
if we're talking sequences".
Basically:
- mypy is broken by design, because it typechecks "python", not "what we
wish python to be"
- we do not actually need to graciously permit passing tuples instead of
lists
As far as historic implementations of this logic go, we have formerly:
- originally, typeslistified anything
- switched to accepting list from the interpreter, redundantly ran list()
on the list we got, and mishandling API violations passing a string
(commit 11f96380351a88059ec55f1070fdebc1b1033117)
- switched to accepting anything, stringlistifying it if it was not
`None`, mishandling `[None]`, and invoking list(x) on a brand new list
from stringlistify (commit 157d43883515507f42618b065a64fb26501734a0)
- stopped stringlistify, just accept T.List[str | None] and re-cast to
list, violates typing because we use/handle plain None too
(commit a8521fef70ef76fb742d80aceb2e9ed634bd6a70)
- break typing by declaring we accept a simple string, which still
results in mishandling by converting 'foo' -> ['f', 'o', 'o']
(commit ac576530c43734495815f22456596772a8f6a8cc)
All of this. ALL of it. Is because we tried to be fancy and say we
accept T.Tuple; the only version of this logic that has ever worked
correctly is the original untyped do-all-validation-in-the-build-phase
typeslistified version.
Let's just call it what it is. We want a list | None, and we handle it too.
|
|
Java module 1.0.0 updates
|
|
Remove the note about the unstable API of the Rust module, since it's no longer unstable as of Meson 1.0.0.
|
|
|
|
This follows the Meson naming scheme which typically leaves off a verb
like generate.
|
|
This API existed for 2 minor releases and was worthless for pretty much
every usecase.
|
|
This is no longer implicitly installed due to libxslt. Actually though,
we don't need to test this in order to ensure that the custom dependency
works -- we have other jobs that test it, and the config-tool handling
itself won't suddenly fail on msys2 specifically.
|
|
|
|
In particular, CUDA 12 removes support for Kepler (3.x) entirely.
Unusually, however, it does not introduce any new architectures,
or even compute capabilities.
|
|
|
|
Add a `dependencies` keyword argument to bindgen
|
|
|
|
|
|
devenv: various improvements
|
|
When finding a py.dependency() we try to use pkg-config. We then apply
our own custom base class, which replaces self.name with the informative
comment "override the name from the "real" dependency lookup", to which
I can only say "uhhh why". Why do we want to do that???
It turns out we don't, it was just a really old legacy design because we
had a SystemDependency with a .pkgdep attribute hiding the real
dependency bizarro-land style. We cleaned that up in commit
4d67dd19e5b7dcec6716840d30984fa41eef55c6 and as part of that, we
*shifted over* the self.name assignment to preserve the visible effects,
sort of. We didn't have a *reason* to override the name, we just did it
because... we weren't sure whether it mattered.
Unfortunately it very much does matter the other way -- we don't want
it. We can pass this dependency to the pkgconfig module, which uses the
name attribute to fill out the `Requires: ` field. Also, the name should
name what we have. :p
Get rid of this bizarre historic quirk. Since we have proper
dependencies here, we should go all in.
Fixes https://github.com/ufo-kit/ufo-core/pull/185#issuecomment-1328224996
|
|
|
|
Fixes #10931
|
|
|
|
When the cross file has a sys_root, it is most probably needed to run
executables with qemu.
|
|
It is only used by Environment.get_exe_wrapper() and every callers were
handling None already. Type annotation was wrong, it already could
return None for the case an exe wrapper is needed but none is provided.
|
|
Cross compiled executables could still be run with an exe wrapper, or
with proper binfmt installed.
Fixes: #10999
|
|
Handles the case when wine-binfmt is installed, which makes .exe files
executable without without specifying an exe wrapper.
|
|
This makes --dump print variables like `FOO=/path:$FOO:/another/path`.
|
|
|
|
|
|
|
|
Now that top builddir is not the default workdir any more, the .gdbinit
file we write there won't be loaded automatically unless user cd there,
or use --init-command. There is also a global setting that user has to
set to allow automatically loading .gdbinit file.
|
|
Most of the time it is preferable to remain the the top source dir
instead of going into the builddir. Add --workdir argument to be able to
have a different workdir than builddir, but keep it default to builddir
for backward compatibility, and also because it makes gdb integration
better.
|
|
In commit a7e458effadbc884eacf34528df3a57b60e43fe3 we stopped erroring
out on invalid TAP stream contents, with the rationale that "prove" has
become more lenient.
A close reading of the TAP spec indicates why, though:
> A TAP parser is required to not consider an unknown line as an error but
> may optionally choose to capture said line and hand it to the test
> harness, which may have custom behavior attached. This is to allow for
> forward compatability. Test::Harness silently ignores incorrect lines,
> but will become more stringent in the future. TAP::Harness reports TAP
> syntax errors at the end of a test run.
The goal of treating unknown lines as an error in the TAP parser is not
because unknown lines are fine and dandy. The goal is to allow
implementing future versions of TAP, and handling it via existing
parsers. Since Meson has both a parser and a harness, let's do exactly
that -- pass these lines as a distinctive status to the test harness,
then have the test harness complain.
|
|
Just like comment lines, blank lines do nothing. Before commit
a7e458effadbc884eacf34528df3a57b60e43fe3 we ended off the parser by
returning if the line was blank, because we needed to in order to catch
non-blank lines as errors. But really, we should have always returned
much earlier and not wasted time attempting to process anything.
|
|
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
|
|
Due to a deficiency in upstream clang-format, our automatic target for
`ninja clang-format-check` runs clang-format, then compares the bytes of
the file before and after to see if anything changed. If it did change,
we rewrite the file back to its original form and error out.
Since clang-format 10, there is an option to report warnings instead of
writing the reformatted file, and also, to make those warnings fatal.
This is a much better user experience, to see *what* is wrong, not just
that something is wrong, and also gets rid of a pretty gross "modify
your files when you didn't ask for it" behavior that is vulnerable to
getting interrupted.
Let's switch over to the new approach, if we can.
|
|
This is needed for cases where we need external C headers, which are
passed to clang.
|
|
|
|
|
|
Which we support for basically every other case, but not this one.
|
|
The Interpreter has a method for this, and the module state just wraps
it.
|
|
|
|
Because sometimes we simply need to open code FeatureNew and
FeatureDeprecated checks, but in a re-usable way.
|
|
Since it's also used in the rust module, it should be in a common place.
Also rename from `TEST_KWARGS` to `TEST_KWS`, which is more in line with
the `*_KW` naming scheme used in the type_checking module.
|
|
Fixes the following warning when building a rpm pkg using %meson macro:
WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
|
|
|
|
I accidentally followed a very old link and was briefly discombobulated.
To save other people from this mistake, use the current location
of the Meson repository, and tweak the surrounding text so it is
more clear that it was written nearly 10 years ago.
Signed-off-by: Tony Finch <dot@dotat.at>
|
|
Due to an accidentally repeated line it would print twice unless
required.
Fixes #8150
|
|
We do some magic to figure out what names of pkg-config dependencies to
even search for. This magic simply checked for `pkg-config` the $PATH
executable, which was broken in a variety of ways and had a comment to
that effect.
|
|
The pkg-config dependency class has some interesting logic for finding a
good pkg-config that will be used for dependency lookups. We sometimes
need to use it, though, outside of the class. Make that possible.
|
|
Signed-off-by: Alex <aleksandrosansan@gmail.com>
|
|
The previous description update was lacking an example of why
external_program cares about inter-target dependencies.
|
