On Fri, Oct 18, 2024 at 11:28:53AM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > > On Fri, Oct 18, 2024 at 10:51:03AM -0300, Fabiano Rosas wrote: > >> Daniel P. Berrangé <berra...@redhat.com> writes: > >> > >> > That could be a good reason to split the migration-test into > >> > two distinct programs. One program that runs for every target, > >> > and one that is only run once, for some arbitrary "primary" > >> > target ? > >> > >> What do you mean by distinct programs? It's not the migration-test that > >> decides on which targets it runs, it's meson.build. We register a test() > >> for each target, same as with any other qtest. Maybe I misunderstood > >> you... > > > > If we split, we could have meson.build register "migration-smoketest" > > for every target while registering "migration-bigtest" for just 1 target. > > Isn't that a bunch of shuffling code around just to have two different > invocations of migration-test?
Yes, pretty much, but that's not an inherantly bad thing. Migration is a bit of an outlier in its attempt to test the entire subsystem from a single test binary. > There's the possibility of using the gtester path like > /x86_64/migration/smoke and passing '-r' when invoking via meson. That > requires way fewer changes in the C code. It moves the complexity into > meson.build, which might be worse. > > Alex's idea of full set for KVM arch + a TCG arch would probably be > trickier in meson. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
