In commit 4e4f97edb3 we added support for
runpython to accept `-c 'code to execute'` in addition to just script
files. However, doing so would mangle the sys.argv in the executed code
-- which assumes, as python itself does, that argv is the stuff after
the code to execute. We correctly handled this for script files, but the
original addition of -c support pushed this handling into a script-file
specific block.
We have functionality to squelch logging, and we use this for situations
where we run a fake interpreter and then emit output. e.g. `introspect`.
It's reasonable to avoid logging your bog-standard noisy `mlog.log()`
here, but unfortunately, we also avoided logging the output of
`mlog.exception()` followed by `sys.exit(2)`, because that went through
mlog! :P Special-case this to keep on printing, even if mlog.disable()
was used -- in such a case, we really do want to emit log output no
matter what. Users need this info to ensure they have any clue why Meson
returned a non-zero exit code.
llvm-config is unsuitable for standard cross-compile,
because we need to build llvm especially for it, which
is not done is almost any distros, so, for example,
standard bootstrap chroot will be unsuitable.
This patch is trying to acheive feature parity between
config-tool searching of LLVM and CMake-based one,
which is arch-agnostic.
Signed-off-by: Konstantin <ria.freelander@gmail.com>
Partial rollback of commit b7a5c384a1. The
rationale was based on a confusing wording of the TAP14 spec, which is
under discussion for clarification / amendment.
TAP14 doesn't (shouldn't) really say that missing a version line is
potentially an error. Rather, this is the correct way to denote TAP12,
which a TAP14 harness may not understand or try to parse. The intention
was never to suggest that harnesses "should" take exception to the
missing version line on the grounds that one should really add a version
line.
So, stop emitting an annoying warning for something that's valid usage.
Meson understands TAP12 and that's okay.
However, we do need to keep the part of that commit which set the
version to 12 if it was otherwise unspecified. But instead of
distinguishing between None and a version, just default to 12.
This reverts commit 79d7891746.
This debug print probably should not have ended up live. Moreover, the
function it debugs is, surprisingly, called rather often. Adding I/O to
it causes it to begin to noticeably lag, on the scale of adding actual
*minutes* to a setup run.
Fixes#11322
Currently Meson allow the following (Muon does not):
```meson
option('foo', type : 'boolean', value : 'true')
option('bar', type : 'integer', value : '42')
```
This is possibly a holdover from very old code, but it's a bad idea and
we should stop doing it. This deprecation is the first stop on that
journey.
We make use of allow_unknown=True here, which allows us to only look at
the common arguments in the main option parser, and then look at the
specific options in the dispatched parsers. This allows us to do more
specific checking on a per overload basis.
Currently in our deprecated/new feature printing we carefully sort all
of the values, then put them in a set to print them. Which unsorts them.
I'm assuming this was done because a set looks nice when printed (which
is true). Let's keep the formatting, but print them in a stable order.
Instead of setting it to `Optional[bool] = None`, and then in the
initializer replacing `None` with `DEFAULT_YIELDING`, just set to to
`bool = DEFAULT_YIELDING`
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
The latest release of libpcap added argument validation to pcap-config,
but still doesn't support --version. The next version of libpcap will
support --version.
Add support for config-tool dependencies which expect to break on
--version, to fallback to an option that does not error out or print
version info, for sanity checking.
We have to allow through build.BuildTarget and build.ExtractedObjects,
which is what our previous level of checking did, even though they are
ignored. I've used FeatureDeprecated calls here, so that we have a clear
time of "this was officially deprecated in 1.1.0"
When a compiler is initialized, it adds specific options that it
supports, but taking some global UserOption objects and adding them to
itself. When it does so, it mutates then if necessary. This means that
each compiler initialized mutates global state, this is bad. This is
worse because in our test suite we do in process testing, so these
mutations are preserved *between tests*, potentially leading to
incorrect results. The simple fix is to do the right thing, and copy the
UserOption before mutating. A deepcopy is required because the option
might be an ArrayOption, and a shallow copy is not sufficient in that
case.
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
EnvironmentVariables was always broken, it used MutableMapping because
everyone <3 abstract interfaces, especially when they are broken and
don't actually do what you want.
This needs a dict interface, exposing `.copy()`. We either use a dict or
os._Environ, and the latter also supports that.
Also fix a broken import, and the fallout from forgetting to update the
signature of self.envvars in commit b926374205.
The code below this already handles being passed an Executable or
ExternalProgram, and it does it correctly, since it handles host
binaries that need an exe_wrapper correctly, while the code in the
generator paths doesn't.
The xcode backend is, like always, problematic, it doesn't handle things
the same way as the ninja and vscode backends, and generates a shell
script instead of using meson as a wrapper when needed (it seems likely
that just forcing the meson path for xcode would be better). I don't
have a working mac to develop a fix for, so I've left a todo comment
there.
Fixes: #11264
In some cases we'll get an `ImmutableListProtocol[str]` anyway (and
actually, we should probably be getting one in call cases), since we
don't mutate it anyway, just store it as immutable.
Mainly thi sis that `state.find_program()` is annotated incorrectly, it
returns `ExternalProgram | Executable | OverrideProgram`, but it's
annotated to return only `ExteranlProgram`, and thus a bunch of the
annotations in the gnome module are wrong.
It is possible, albeit possibly inadvisable, for the exact combination
of MSVC and "$CXX has C++ specific flags in it" to occur. When this
happens, and cl.exe is given a filename ending in .c, it complains that
you cannot compile a .c file with that option.
Instead, pick the first filename matching that language and use that as
the temporary filename. This more or less matches what we do in
compiler-time checks. And it's the proper thing to do, rather than
assume that cl.exe, when detected as the current C++ compiler, can
*also* compile C because it's *also* a C compiler.
Fixes#11257
`get_event_loop()` would always implicitly create one on demand, but
Python upstream has decided it's a bad/confusing API. Explicitly
starting our own, then setting it, is exactly equivalent other than not
being scheduled for deprecation.
These functions constantly want the current asyncio loop, and we run a
function call each time to get it. And the function call is a deprecated
one. Python 3.7 brings the more explicit get_running_loop for use when
we know we're inside one, with the aim of getting rid of get_event_loop
once support for python <3.7 disappears. Meson no longer supports python
<3.7 either.
Switch to the new API, and save the reference for reuse instead of
constantly re-calculating it.
Charles Brunet
David Seifert
Eli Schwartz
Konstantin
Thibault Saunier
X512
Dylan Baker
Xavier Claessens
Gijs Peskens
Thomas Li
jack
Jan Janssen