Link to feature options consistently, and point out that it controls
"whether" the function finds what it's trying to find. This clues people
in to the fact that disabled features exist.
fix_jar() tries to remove an existing Class-Path entry from the jar
manifest by postprocessing the manifest and passing it to `jar -um`.
However, `jar -um` can only add/replace manifest entries, not remove
them, and it also complains loudly when replacing an entry:
Dec 13, 2022 7:11:19 PM java.util.jar.Attributes read
WARNING: Duplicate name in Manifest: Manifest-Version.
Ensure that the manifest does not have duplicate entries, and
that blank lines separate individual sections in both your
manifest and in the META-INF/MANIFEST.MF entry in the jar file.
Thus fix_jar() produces one such warning for each entry in the manifest
and accomplishes nothing else.
Use jar -uM instead. This completely removes the manifest from the jar
and allows adding it back as a normal zip member, fixing fix_jar() and
avoiding the warnings.
Fixes: https://github.com/mesonbuild/meson/issues/10491
Fixes: c70a051e93 ("java: remove manifest classpath from installed jar")
Rather than passing arguments directly to less, set the LESS environment
variable to contain the desired arguments instead. This allows passing
arguments in case the user has PAGER=less set in their environment.
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 11f9638035)
- 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 157d438835)
- stopped stringlistify, just accept T.List[str | None] and re-cast to
list, violates typing because we use/handle plain None too
(commit a8521fef70)
- break typing by declaring we accept a simple string, which still
results in mishandling by converting 'foo' -> ['f', 'o', 'o']
(commit ac576530c4)
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.
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.
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
4d67dd19e5 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
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.
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 a7e458effa 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
a7e458effa 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.
Eli Schwartz
Benjamin Gilbert
Brad Smith
Andreas Deininger
Phil Jones
Jussi Pakkanen
Ewout ter Hoeven
Tristan Partin
Olexa Bilaniuk
Xavier Claessens
L. E. Segovia
Marvin Scholz
Angelo Haller
Dylan Baker