Type annotation, documentation string, and implementation were doing 3
different things. Change implementation to match type annotation which
makes the most sense because it match what get_target_sources() does.
All callers only use keys from the returned dictionary any way, but
that's going to change in next commits.
This allows early exit of the project tests once a certain number of
failures are detected. For example `meson test --maxfail=1` will abort
as soon as a single test fails.
Currently running tests are marked as failed via INTERRUPT.
Resolves#9352
This was initially added in eb76ba7031 to avoid picking
it up from azure/gha images.
Looks like it is no longer set for some time now though:
https://github.com/actions/runner-images/pull/540
so should no longer be needed.
The empty string makes some meson tests fail which expect a path.
A recent msys2-runtime change now lets empty env vars through to child processes
whereas before they would get filtered out, which is why this worked before.
This does force a number of uses of `# pylint: disable` comments, but it
also finds a couple of useless global uses and one place (in the
previous commit) that an easy refactor removes the use of global. Global
is a code smell, so forcing adding a comment to disable helps force
developers to really consider if what they're doing is a good idea.
The `global` statement is only needed to assign to global variables, not
read or mutate them. So calling `global.mutate()` is fine, but not
`var = foo`, which would otherwise shadow `var`.
This removes the need for the use of the global statement. I've also
updated the test that overrides this to use mock.patch instead of hand
monkey patching.
We *mostly* just need to do the same thing. Plug in one utility method
to make sanity_check_impl find the right compile args, and plug in
DEVNULL to the test run. It's that simple.
This solves a few inconsistencies. The main one is that fortran never
logged the sanity checks to the Meson debug log, making it hard to
debug.
There's also some interesting quirks we built up in the dedicated
fortran handling. For example:
- in commit 5b109c9ad2 we added cwd to
building the fortran executable, with a wordy comment about how the
compiler has defects. But the clike base has always done that on
general principle anyway, so we would never have had that bug in the
first place.
- in commit d6be7822a0 we added special
deletion of an old "bad existing exe file" just for fortran. Looking
at the PR discussion for this odd requirement, it turns out that the
real problem is mixing WSL and native Windows without deleting the
build directory. This is apparently fortran specific simply because
"contemporary Windows 10 Fortran users" switch between the two?
The actual problem is that this never used .exe as the output name, so
Windows thinks you want to run something other than the thing you
asked to run, because it's not even a Window executable. But... the
common clike handling could have fixed that without needing special
cases.
Currently it repeats the text of the exception, which appeared
immediately above. And strerror is already part of args, so that was
then doubled. `str(e)` formats this much better anyway.
While we are at it, point out that it is probably a build environment
issue, rather than just saying "this is probably not a meson bug". The
former comes across a bit more as constructive advice rather than just
"idk but it's not our fault".
In commit fa044e011d we caught OSError and
started emitting a special error message disclaiming that it probably
isn't Meson's fault, and skipping the generic "This is a meson bug and
should be reported" handler.
But, we no longer did this after verifying that the command *isn't*
runpython, so arbitrary scripts that raised OSError would start saying
stuff about Meson, which was wrong.
Start checking for runpython first.
In commit 9ed5cfda15 we refactored
startup to be a bit faster and import less. But this had the side effect
of moving out of our errorhandler. Refactor this so it can be easily
used elsewhere.
"MSYSTEM= python ..." no longer works because of some changes in the MSYS2 runtime
Until this is fixed in either MinGW Python or the MSYS2 runtime this should revert
things to the previous behaviour to get the CI green again.
This makes it much easier to see what we're ignoring, as well as
allowing pylint to enforce any lints that currently pass but aren't in
the allow list automatically.
This used to be fine, until imports were removed from this file. Now a
function annotated as T.NoReturn doesn't actually tell mypy that it
cannot return, though, so we manually do it.
We no longer need these upfront at all, since we now import the ones we
need for the language we are detecting, at the time of actual detection.
This avoids importing 28 files, consisting of just under 9,000 lines of
code, at interpreter startup. Now, it is only imported depending on
which languages are invoked by add_languages, which may not even be
anything. And even if we do end up importing a fair chunk of it for
C/C++ projects, spreading the import cost around the interpreter runtime
helps responsiveness.
Only import the ones we need for the language we are detecting, once we
actually detect that language.
This will allow finally dropping the main imports of these files in a
followup commit.
Instead of comparing against specific compiler classes, check the
logical compiler id or language etc.
In a couple cases, we seem to be missing a couple things by being a bit
too strict about the exact class type.
We want to optimize out some internal codepaths used at build time by
avoiding work such as argparse. This doesn't work particularly well when
the argparse arguments are imported before then. Between them, they
indirectly import pretty much all code anywhere, and msetup alone
imports most of it.
Also make sure the regenerate internal script goes directly to msetup.
This is wasteful and generally unneeded, since code can just use the
compiler they detected instead of manually poking at the internals of
this subpackage.
It also avoids importing an absolute ton of code the instant one runs
`from . import compilers`
It turns out we don't generally need to proxy every compiler ever
through the top-level package. The number of times we directly poke at
one is negligible and direct imports are pretty clean.
In various situations we want to figure out what type of compiler we
have, because we want to know stuff like "is it the pgi one", or "does
it use msvc style". The compiler object has this property already, via
an API specifically designed to communicate this info, but instead we
performed isinstance checks on a compiler class.
This is confusing and indirect, and has the side effect of requiring
more imports everywhere. We should do away with it.
Xavier Claessens
Tristan Partin
Eli Schwartz
Christoph Reiter
Dylan Baker
Vili Väinölä