On 6/3/2026 12:03 PM, Alex Bennée wrote: > 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. >
Yes, this should give us a good taste of what it will look like. > 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). > 100% agree. Even if it's a slow development over months, we'll replace Makefiles only once all the features are properly covered. > <snip> > Regards, Pierrick
