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.
There is no need to state for every single test that "preconditions were
not met". And logging the skip reason for a single test is easy to read,
but making every second line alternate is less so.
Partial revert of commit cf23e34187. This
mostly moved existing arguments to the "right" location, but also
introduced new arguments that didn't previously exist -- which was
wrong.
... also, these cross files are used by CI (if they have a corresponding
.json file) and this change broke the CI. Because --target isn't a valid
gcc option, although clang/rustc do accept it. For GCC, the argument
parser decides you wanted --target-help, which prints documentation text
and then quits.
c_args are meant to be overridden by the user if needed (even via the
environment CFLAGS variables + -Doptimization=plain, for example),
so they should not contain any option that affect the multilib search
path. For example, a hypothetical native file like this:
[binaries]
c = gcc
[built-in options]
c_args = ['-m32']
would *not* build 32-bit binaries if -Dc_args is passed to meson.
Such options, instead should be in the [binaries] section. Adjust
the sample cross files included with meson.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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.
From the Zen of Python: "Explicit is better than implicit."
As it turns out, it's no longer a safe assumption that pip uses
setuptools??? Well, anyway, install it properly regardless.
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.
Fix a TODO comment about moving to asyncio.run, now that we use
sufficiently new python to do it.
Note that we create an event loop for Windows using the new python
defaults, but in a completely different part of the code from where we
need to use it. Since asyncio.run creates the loop on its own, we need
to set the default policy instead -- which we probably should have done
all along.
In https://bugs.python.org/issue42392 this stopped implicitly creating
an event loop if none exists. We created it before running _run_tests(),
so it would auto-create an event loop and set the default, which means
we cannot create one explicitly on our own schedule or we end up with
two of them.
Delay this until we actually start the logger. This happens inside the
actual testsuite loop, so it finds the running loop and doesn't create a
new one, even on python <3.10.
Useful for running the testsuite with this environment variable and
catching obscure issues. Just like with the encoding warning later down,
we have to do this inside meson itself, not externally injected.
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
It's probably not useful to spam the user with warnings that old
versions of software may not behave correctly when the first warning was
perfectly valid.
There are lots of warnings that become fatal, that are simply unfixable
by the end user. Things like using old versions of software (because
they're using some kind of LTS release), warnings about compilers not
supporting certain kinds of checks, or standards being upgraded due to
skipped implementations (MSVC has c++98 and c++14, but not c++11). None
of these should be fatal, they're informative, and too important to
reduce to notices, but not important enough to stop meson if they're
printed.
Dylan Baker
Eli Schwartz
Xavier Claessens
Yue Yang
Gijs Peskens
Thomas Li
Paolo Bonzini
jack
Jan Janssen
andy5995
Luke Elliott