Pierrick Bouvier <[email protected]> writes: > On 5/28/2026 3:13 AM, Alex Bennée wrote: >> Pierrick Bouvier <[email protected]> writes: >> >>> On 5/26/2026 11:17 PM, Alex Bennée wrote: >>>> Pierrick Bouvier <[email protected]> writes: >>>> >> <snip> >>>> >>>> What do you mean? I run check-tcg all the time. >>>> >>>> Which containers fail to build for you? The main cross-compiler one >>>> (debian-all-test-cross) is built all the time. >>>> >>> >>> Build is working out of the box now. >>> However, it seems that only tests for aarch64, arm and x86_64 are run >>> when using containers without having installed cross compilers. >>> Maybe it's another carefully handcrafted feature of tcg Makefiles? >> >> Works for me over here. Do you have podman or docker installed? >> >> It's true the Makefile has to jump through some hoops to compute >> TCG_TESTS_TARGETS from TCG_TESTS_WITH_COMPILERS (config-host.mak) and >> CONFIGURED_TCG_TARGETS (via $(wildcard *-config-target.h)). Is that >> where it fails? >> > > Maybe, I reproduced that on two different machines, with different > architectures. As you know, Makefiles are complex to debug, which is one > of the reason I would like to get rid of it completely. > > I prefer to spend time replacing this, instead of investigating N days > to understand why a dependency is missing (similar to the current patch) > and solve it by adding new cryptic lines in an existing Makefile. > >> As I've said before I'm not wedded to Makefiles, in fact I would look >> forward to a world when I can run an individual test directly from >> meson. However I'm not prepared to throw away functionality, especially >> the ability of new developers/testers to build the tests without having >> to install cross-compilers. That would take us back to the *before >> times* when TCG tests where hardly ever run and tended to bitrot. >> > > Sure, I agree with you. The transition should not change anything, > except how to run a single test. We can easily replicate the container > functionality in meson I think. > > I just had the impression, previously in this thread, that instead of > saying "Sounds good, let's explore the meson approach", the tone was > more "this is wrong and this can't work, please don't touch this". Maybe > it's just a communication issue. > > I made the effort to show a minimal example to prove you can compile > stuff without having to declare a toolchain in meson, which was the > "blocker" you mentioned. The rest, multi files tests and using a > container instead of an installed cross compiler, are just small > details. The key is "we can build a custom binary using a custom command > with meson", and that's all we need to move forward. > >>>>> But well, if the cross-container thing is *really* a blocker, we can >>>>> just wrap build and run in a script per cross compiler, that does >>>>> docker/podman build && docker/podman run and call that. >>>> >>>> We still have the remnants of that in the docker.py script although for >>>> most containers we moved to invoking docker (or podman) directly. >>>> >>> >>> Maybe that's why I encountered issues in the past, and now it works out >>> of the box. >> >> The original script attempted to deal with caching layers and the >> consequences of custom USER/UID on local machines. Nowadays it is mostly >> used as a basic wrapper around "probe" for the runtime and is still used >> by the binfmt_misc and toolchain wrappers. >> >> For porting to meson it might be worth just having a minimal wrapper >> just for building rather than mess with it. >> > > Yep. > >>>> Also bear in mind the containers are also used to cross build QEMU >>>> itself. >>>> >>>>> >>>>> Now we solved the problem with system tests, and cross compilers, is >>>>> there another thing that is absolutely needed from Makefiles? >>>>> >>>>>>> If it's not the case, then we should definitely move into the direction >>>>>>> of migrating all this to meson, and rely on meson tests infrastructure. >>>>>>> >>> >>> To add on top of this, I would be happy to help with the transition, but >>> I want to make sure you'll accept it first, with a list of >>> requirements. >> >> For check-tcg the requirements are simple: >> > > Thanks for listing them. We can have specific test suites to address the > categorization. For the rest, there is nothing custom targets won't be > able to solve. >> - support building tests with containers >> - handle all existing tests >> - per-arch *-user and *-softmmu >> - including post test validation checks (conditional-diff-out, >> validate-memory-counts.py, etc...) >> - per-target overrides (some targets are broken for some tests) >> - custom QEMU_OPTS for some tests >> - including sub-arch tests (e.g. x86_64 includes i386, mips64el >> includes mips64 etc...) >> - multiarch tests for all *-user targets >> - multiarch tests for all *-softmmu targets with boot.S >> - gdbstub tests >> - don't forget gdb feature probing for arch and arch features (e.g. >> GDB_HAS_SME_TILES) >> - record/replay tests >> - tcg plugin tests >> - modulate plugins over tests to avoid combinatorial explosion >> - filter some plugins from general testing (e.g. patch) >> - filter some plugins based on mode (e.g. syscall) >> - specific plugins with specific tests (e.g. patch, memory) >> - support build variations >> - compiler feature probing to gate tests >> - custom cflags for some tests >> - alternate cflag builds for some tests (e.g. >> sha512-[vector|sse|mvx|...]) >> - build scripts (e.g. test-mmx.py) > > I have a proposal: How about I give it a try with a specific target > (let's say aarch64?), to try to cover user, system, and multi arch > tests, without the cross container as a first step. > > This way, we can focus on testing part, agree on what works, what > doesn't, and iterate until having something nice. > Then, we can add cross container support, and finally add the rest of > targets. Once all of them are implemented, we can migrate check-tcg > command to this.
I think that's a reasonable plan. We can certainly test and review patches as we try different things out. aarch64 is a good first target as it has user, softmmu and plugin specific tests. What we can't do is merge piecemeal so I'd want a complete conversion before we merge so we don't end up with a half-functional port to meson in the tree (the bane of QEMU's API conversions). <snip> -- Alex Bennée Virtualisation Tech Lead @ Linaro
