On 23.08.2017 10:01, Paolo Bonzini wrote: > On 23/08/2017 09:49, Thomas Huth wrote: >> While we're at it: I'd like to have a "make check-fast", too. Sometimes >> the normal "make check" is already too slow, e.g. while developing new >> patches, I sometimes just want to do a very quick sanity test to see >> whether I broke some basic things or not, and only do the "make check" >> before I submit my patches. >> So we would get three stages: >> >> - make check-fast => For very, very quick sanity tests only >> >> - make check => E.g. has to be run before submitting patches >> >> - make check-harder => might run a very long time, so best suited for >> nightly regression tests etc.? >> >> Does that sound reasonable? And the crucial question: Who is going to >> implement the basic framework for this? > > There's already make check-unit or make check-qtest-x86_64 depending on > what you're working on.
True. And I just learned that you can also already set the SPEED variable to either "quick" or "slow" and that we're already using g_test_quick() and g_test_slow() in a couple of places to check this. So the framework for running quick vs. thorough tests is already there ... we just might want to add this to some more tests, I guess... Question for the maintainers and the test automation folks: Is anybody already running "make check SPEED=slow" or is this just rather an unheard-of way of running the tests? > If you have a many-core machine, of course, there's no simpler solution > than throwing more CPUs at it. :) Is it safe nowadays to run "make check -j4" for example? Last time I tried (maybe 1 or 2 years ago), there were still issues since some tests were using hard-coded temporary file names, so the parallel tests were disturbing each other, for example... Thomas
