This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
CI runs with vs2019 and we were passing --backend=vs. This fix
reconfigure tests because we can't reconfigure with --backend=vs when
initial configuration determined the backend is actually vs2019.
In commit faf79f4539 we broke this utility
function by referencing a non-existent variable. Fortunately, the only
time we ever used said function was once, and that in a test case where
we tested that it raised a MesonException before the undefined variable
error could occur.
python 3.11 adds a warning that in 3.15, UTF-8 mode will be default.
This is fantastic news, we'd love that. Less fantastic: this warning is
silly, we *want* these checks to be affected. Plus, the recommended
alternative API would (in addition to warning people when UTF-8 mode
removed the problem) also require using a minimum python version of 3.11
(in which the warning was added) or add verbose if/else soup.
The simple, and obvious, approach is to add a warnings filter to hide
it.
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.
Unfortunately, checking for strings without context is exceedingly prone
to false positives, while missing anything that indirectly opens a file.
Python 3.10 has a feature to warn about this though -- and it uses a
runtime check which runs at the same time that the code fails to open
files in the broken Windows locale. Set this up automatically when
running the testsuite.
Sadly, Python's builtin feature to change the warning level, e.g. by
setting EncodingWarning to error at startup, is utterly broken if you
want to limit it to only certain modules. This is tracked in order to be
more efficiently ignored at https://bugs.python.org/issue34624 and
https://github.com/python/cpython/pull/9358
It is also very trigger happy and passing stuff around via environment
variable either messes with the testsuite, or with thirdparty programs
which are implemented in python *such as lots of gnome*, or perhaps
both.
Instead, add runtime code to meson itself, to add a hidden "feature".
In the application source code, running the 'warnings' module, you can
actually get the expected behavior that $PYTHONWARNINGS doesn't have. So
check for a magic testsuite variable every time meson starts up, and if
it does, then go ahead and initialize a warnings filter that makes
EncodingWarning fatal, but *only* when triggered via Meson and not
arbitrary subprocess scripts.
Instead of blindly assuming when $CI is set that `ninja` is always
correct and always new enough, check for it the same way we do when $CI
is not set.
Instead of special casing when $CI is set and skipping ninja detection
in subprocess tests (by assuming it is always `ninja`), skip detection
in subprocess tests all the time, by passing this information around
across processes after the first time it is looked up.
This means that local (non-CI) tests are faster too!
Fixes running unittests in alpine linux using samu. Although ninja is a
symlink to samu, the exact output string on no-op builds is different,
which we already handle, but what we don't handle is the fact that samu
prints a third case when you invoke it as `ninja`. If $CI is exported,
then the unittests ignored $NINJA entirely.
Fixes running unittests when $CI is set, `samu` exists and `ninja` does
not exist. This is not currently the case anywhere, but may be in the
future; why not fix it now?
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
All changes were created by running
"pyupgrade --py3-only --keep-percent-format"
and committing the results. I have not touched string formatting for
now.
- use set literals
- simplify .format() parameter naming
- remove __future__
- remove default "r" mode for open()
- use OSError rather than compatibility aliases
- remove stray parentheses in function(generator) scopes
As a Meson developer it's often frustrating to have a single functional
test with a regression. These tests can be awkward to reproduce,
especially when they make use of a test.json file. This script provides
a simmple interface to call functional tests 1 at a time, regardless of
whether they use a test.json or not. If they do use a test.json, and
have a matrix, then the `--subtest` option can be used to select spcific
combinations, for example:
```sh
./run_single_test.py "test cases/frameworks/15 llvm" --subtest 1
```
will run only the second (zero indexed of course) subtest from the llvm
test cases.
This is not a super elegent script, but this is super useful.
Automatically colorize the text when printing the AnsiDecorator, based
on the result of mlog.colorize_console(). This is how AnsiDecorator
is used most of the time anyway.
This patches takes the options work to it's logical conclusion: A single
flat dictionary of OptionKey: UserOptions. This allows us to simplify a
large number of cases, as we don't need to check if an option is in this
dict or that one (or any of 5 or 6, actually).
There are two problems here. The first is that we're doing manual monkey
patching which is fragile and verbose, when unittest.mock is designed
specifically to solve this exact problem. The second is that we're
monkey patching os.environ at two different levels with the same
information. So let's only do it once.
Add '--cross-only' option to run_tests.py, so we can arrange not to run
tests in the 'native' suite when only a cross-compiler is available, as
they can't succeed.
on some systems, tests may take over an hour to run--only to find
you might have used an unintended Meson version (e.g. release instead
of dev). This change prints the Meson version at the start of the
run_*tests*.py scripts.
Also, raise SystemExit(main()) is preferred in general over
sys.exit(main())
D lang compilers have an option -release (or similar) which turns off
asserts, contracts, and other runtime type checking. This patch wires
that up to the b_ndebug flag.
Fixes#7082
Currently, colourize_console is a constant, set at process
initialization.
To allow the actual stdout to be easily compared with the expected when
running tests, we want to allow colourization to be on for the test
driver, but not for the in-process configure done by run_configure,
which has stdout redirected from a tty to a pipe.
v2:
Cache _colorize_console per file object
v3:
Reset cache on setup_console()
A current rather untyped storage of options is one of the things that
contributes to the options code being so complex. This takes a small
step in synching down by storing the compiler options in dicts per
language.
Future work might be replacing the langauge strings with an enum, and
defaultdict with a custom struct, just like `PerMachine` and
`MachineChoice`.
This is more correct, and forces the target(s) to be rebuilt if the
PDB files are missing. Increases the minimum required Ninja to 1.7,
which is available in Ubuntu 16.04 under backports.
We can't do the same for import libraries, because it is impossible
for us to know at configure time whether or not an import library will
be generated for a given DLL.
Pull the crossfile specification out of run_test.py so it can be
specified in the CI job configuration.
Also make some fixes to output ordering in run_test.py.
* intel-cl tests: more rigorous detection of intent to use Intel Windows compilers
* fortran coarray test: make skipping more robust in that underlying MPI stack is .run()
This is useful for any Fortran coarray work, and especially for intel-cl where multiple Intel compiler
versions are often installed, and the wrong underlying MPI library may be dynamically linked,
and so a runtime check is needed to exercise the MPI stack underlying Fortran coarray.
This is done by
fc.run('sync all; end', dependencies: coarray)
* pep8
Eli Schwartz
Xavier Claessens
Marvin Scholz
Nirbheek Chauhan
Daniel Mensinger
Jussi Pakkanen
Dylan Baker
Paolo Bonzini
Jon Turney
Michael Hirsch
John Ericson
Aleksey Gurtovoy
Michael Hirsch, Ph.D