| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Store return code, test result and additional error directly to the
relevant TestRun instance. This reduces the number of individual
arguments to other relevant functions that need to be passed around and
thus simplifies the code. The test output (and error) were earlier
similarly moved to be stored directly to the TestRun instance for the
same reason.
|
|
By storing test output directly to the TestRun instance we avoid the
need to pass the outputs around in individual function arguments thus
simplifying the code.
The amount of individual arguments will be further reduced in a
future commit.
|
|
|
|
|
|
Write additional metadata such as exit details and try to visually
differentiate the tests better from each other in the (textual) test
logs.
|
|
Make --no-stdsplit option affect test log text files as well. This means
that if the option --no-stdsplit is used only "output" is seen not only
on the console but in the test log text file as well.
|
|
Since running only one test sort of implies --num-processes=1 the "live"
output of the test should be printed out when --verbose option has been
given and running only a single test.
|
|
The only time the argument would matter (console_mode ==
ConsoleUser.STDOUT) never happens as the only time the function is
ever called is when parsing of the output is needed which in turns
implies that console_mode != ConsoleUser.STDOUT.
|
|
|
|
These new functions will be used individually in later commits.
|
|
As fetching the returned data is non-trivial (we e.g. iterate over all
subtest results) it is best not to hide that fact from the caller of the
property / function.
|
|
|
|
|
|
|
|
Which could receive `None | Sequence[Optional[str]]`, but isn't
annotated for the `None`
|
|
and pie"
This reverts commit 5f02d0d9e164a5bcda072d223eaa5bc92b57747e.
Which isn't correct, we have very strange behavior of "force on pie/pic
or let the toolchain do whatever it wants, but you can't turn it off."
|
|
Because everything except ExternalProgram in CustomTarget.sources is a
valid dependency
|
|
|
|
Calling `isinstance(self, X)` is an anti-pattern, we should just be using
inheritance for this, letting the `StaticLibrary` override the method, and
having the base class always return `False`.
|
|
and fix a bug in the backend that the correct annotations uncover
|
|
Since they are actually dependencies out the output not the Generator
itself.
This fixes dependency issues in the ninja backend, allowing Meson to
rebuild more accurately. It also does sometimes in the vs backend, but
there are problems in the vs backend I'm not sure how to solve. The
vsbackend is, itself, so fragile looking I don't want to get too
involved with it.
|
|
This doesn't actually fix the problem, but it provides parity with what
is currently happening. I don't have access to a Windows machine to
further debug, however, so not breaking anything is the best I can do
ATM.
|
|
Any iterable is acceptable, not just Set | OrderedSet
|
|
Which does the same thing, but is a builtin and is more accurate
|
|
|
|
There's no reason for this to be defined at the instance level (and thus
duplicated into each instance, when it's really a class constant.
|
|
|
|
Which can be shared by BuildTarget
|
|
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
|
|
Leak sanitizer can be enabled without the whole AddressSanitizer, this
can be done by passing -fsanitize=leak as documented at [1].
Meson doesn't support this, so add support for it.
[1] https://clang.llvm.org/docs/LeakSanitizer.html
|
|
We might be using all fallbacks, or be super weird and not use
bash-completion, or simply have a different PKG_CONFIG_LIBDIR set. And
devenv already checks whether the dependency is found, but defaults to
required anyway, which is wrong.
|
|
|
|
Currently, the code puts a placeholder in for the first output, then
replaces all of the outputs when it generates final value. Instead,
let's only replace the placeholder value.
|
|
|
|
|
|
CustomTarget allows multiple install dirs, while basically everything
else allows only one. So this provides a shared instance for that.
|
|
It's a `List[str | int]`, just like in the build module. In fact, we
should probably share the same type information between the two.
|
|
|
|
|
|
|
|
This lets us not import quite as much at runtime
|
|
|
|
They're not used outside of the gnome module anyway, and they create
some annoying potentials for dependency loops
|
|
|
|
It was already written in the side menu, but better have it in the page
title too.
|
|
Fix "Tried to grab file outside current (sub)project" error when subproject exists within
a source tree but it is used through a symlink. Using subprojects as symlinks is very useful
feature when migrating an existing codebase to meson that all sources do not need to be
immediately moved to subprojects folder.
|
|
When referring to the custom_target docs, we want to point to the docs
on the function, not the docs on the returned method.
|
|
Logically, i18n.merge_file cannot ever take a MULTI_OUTPUT_KW, but it
does take a CT_OUTPUT_KW-like interface.
Actually trying to pass multiple merge_file outputs causes the
msgfmthelper script to be entirely malformed in the arguments it
accepts, and treat the broken one like a --flag, then exit with argparse
errors.
Even if we somehow assumed that somehow it was designed to actually
allow this, msgfmt doesn't support conceptually passing multiple outputs
so that would be a msgfmt error instead of an error inside the guts of
`meson --internal msgfmthelper`.
Same logic applies again for the itstool command and the itstool
internal helper.
Catch this error at configuration time by using the single-output kwarg
form.
Likewise, it's totally nonsense to accept multiple install_dir or
install_tags, and ever since commit 11f96380351a88059ec55f1070fdebc1b1033117
the CustomTarget itself won't even check this.
|
|
CT_OUTPUT_KW is the same OUTPUT_KW we use in lots of places. The most
distinctive thing about it is not that it's part of custom_target
(basically any other function that uses such a kwarg follows the same
rules due to using CustomTarget under the hood), but the fact that it
takes multiple outputs.
|
|
We validate a few things here, such as the non-presence of '@INPUT' in
an output name. These got moved out of the CustomTarget constructor in
commit 11f96380351a88059ec55f1070fdebc1b1033117 and into KwargInfo, but
only for kwargs that took multiple values. This caused configure_file()
and unstable_rust.bindgen() to stop checking for this.
Add a shared single-output KW and use it in both places. This now
dispatches to _output_validator.
configure_file now validates subdirectories in output names the same way
we do elsewhere, directly in the typed_kwargs and by specifying the
erroring kwarg.
|
