qemu-arm/qemu-riscv: improve tinytest runner so it doesn't need to generate .exp files on disk #15609
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
The qemu-arm and qemu-riscv ports generate a whole lot of .exp files in the
tests/
directory when you run the tests on these ports. This leaves the repo in an unclean state.This PR improves this situation by:
tools/tinytest-codegen.py
script by calling out to Python to run them and collecting the resulting stdout outputbuild/genhdr/tests.h
fileThis results in a clean repo after running the tests. It also means that
run-tests.py
no longer needs a special case to handle the allowed tests for qemu-arm/riscv targets.A bonus of this approach is that it's not much extra work to enable running the tests on qemu-* port using the via .mpy and via native emitter test framework that already exists in
run-tests.py
.Note: this PR builds on #15577.
TODO:
Testing
The qemu-arm tests pass like they did before, but no stray .exp files are generated.
Trade-offs and Alternatives
It's a little slower this way when generating the .exp files but not by much.
An alternative to this approach would be to make the qemu-* ports have a stdio to the outside world for the REPL, then treat the qemu process as a board with a serial port, and run the test suite as it would normally be run for an attached hardware board.