[Bug 20987] New: msi tests can't be run in parallel
http://bugs.winehq.org/show_bug.cgi?id=20987 Summary: msi tests can't be run in parallel Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: testcases AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com We spend an awful lot of time waiting for tests to finish. It'd be awesome if "make -j 100 test" worked. As a first step, let's make the msi tests work in parallel. "make -j100" in the msi directory explodes at the moment because many of the tests use the same filenames. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20987 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20987 --- Comment #1 from Nikolay Sivov <bunglehead(a)gmail.com> 2009-12-11 11:23:59 --- Some progress here - http://source.winehq.org/git/wine.git/?a=commit;h=350cdd2fe5c8ac415787b60324.... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=20987 --- Comment #2 from Austin English <austinenglish(a)gmail.com> 2012-03-27 21:39:55 CDT --- Still present, though I'm tempted to close this WONTFIX (there was some discussion in #winehackers about parallel make test not being supported, with good reason, especially for gui testing..). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=20987 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com --- Comment #3 from Austin English <austinenglish(a)gmail.com> --- *** Bug 36152 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=20987 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED CC| |fgouget(a)codeweavers.com --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- While supporting parallel runs might work for some tests, there are many tests that will conflict with each other: * The DirectX tests that change the screen resolution will conflict with all other GUI tests. * So will user32:sysparams because it changes the size of fonts, borders, etc. * Two sound capture capture tests cannot run at the same time (e.g. winmm:capture and mmdevapi:capture). * Even sound playback tests risk interfering with each other. * Clipboard tests will definitely interfere with each other (only one process can call OpenClipboard() at a time). This will also break user32:edit which contains some clipboard interactions. etc. Keeping track of which tests can be run in parallel and which must be run in isolation is going to be a nightmare. So I think we don't want to fix this. Note: As far as continuous integration platforms (such as the TestBot) are concerned, the solution to this is to run as many VMs in parallel as necessary to achieve the desired throughput. This requires more (Windows) licenses, and virtualisation software that really shields VMs from each other performance-wise. Also this does not help if the goal is to get the result of a specific WineTest run faster. But it's probably the only sane way. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=20987 André H. <nerv(a)dawncrow.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv(a)dawncrow.de --- Comment #5 from André H. <nerv(a)dawncrow.de> --- closing wontfix -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla