<div dir='auto'><div>Can't you just fork winetest, throw out everything unwanted, add some missing features and make that the new testlauncher?<br><div class="gmail_extra"><br><div class="gmail_quote">Am 02.04.2017 11:30 nachm. schrieb Francois Gouget <fgouget@codeweavers.com>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"><br>
One of the hoped for TestBot improvements is to get rid of TestLauncher <br>
and replace it with WineTest on the theory that they perform the same <br>
role.</p>
<p dir="ltr">Indeed both add lines to the test report to identify the start and end <br>
of each test, and they check that the dlls needed for the test are <br>
present (which is buggy in TestLauncher).</p>
<p dir="ltr">However WineTest only deals with Wine's test executables and this leads <br>
to some hardcoded assumptions:<br>
1) It expects to extract the test executables from its own resources.<br>
2) It expects that the executables will be called something like <br>
<dllname>_test.exe and that it means it should check if <dllname> is <br>
usable.<br>
3) It expects that when given the 'list' parameter the executable will <br>
spit out the list of test units to run.<br>
4) Then it expects proceeds to run the test executables with the command <br>
line that it chose.</p>
<p dir="ltr">However the TestBot also lets Wine developers upload any executable they <br>
like and lets them specify the command line they want. This breaks all <br>
the above assumptions.</p>
<p dir="ltr">So, to replace TestLauncher, WineTest would need to be modified so it <br>
can run an arbitrary executable, not from its own resources, using an <br>
arbitrary command line. And it also means merging TestLauncher's code <br>
that dives into the executable's import table to figure out which dlls <br>
are needed, with WineTest's code that has support for activation <br>
contexts (the lack of which is what's causing the bug in TestLauncher if <br>
I understand correctly).</p>
<p dir="ltr">Finally one would also want to be able to build WineTest without any <br>
builtin test executable to get something small enough since it would get <br>
uploaded for each task. And that would still leave all the GUI as dead <br>
weight. As far as I can tell a WineTest with no builtin test still takes <br>
around 87 KB whereas TestLauncher can get under 12 KB.</p>
<p dir="ltr">Even in the patch case there are some issues though these have <br>
essentially been known from the start:<br>
* Currently it's only possible to build WineTest with all the tests, <br>
resulting in a huge executables. Fixing this requires either <br>
bypassing the build system to build WineTest, or tweaking the build <br>
system so one can specify which executables to embed.</p>
<p dir="ltr"> * Even if we embed only one test executable we usually only want to run <br>
one test unit. Fortunately that's already possible by specifying it <br>
on the command line.</p>
<p dir="ltr"> * However, even in the case of a patch the Wine developer can specify <br>
an arbitrary command line. This is probably not very command but do <br>
we want to drop it?</p>
<p dir="ltr"> * Finally WineTest systematically outputs platform information. That <br>
would make every report a bit larger and would force developers to <br>
skip over it most of the time. But it may also be useful sometimes.<br></p>
<p dir="ltr">Given the above I feel like it would be simpler, cleaner and possibly <br>
more maintainable to keep the two separate after all.<br></p>
<p dir="ltr">Of course sticking with TestLauncher would require some work too but <br>
that seems quite tractable:<br>
* First not checking it into Git!<br>
* Making sure it gets updated automatically.<br>
* Fixing the dll checks.<br>
* Bringing it in line with the latest changes w.r.t. pids, run tmie <br>
data, etc.<br></p>
<p dir="ltr">-- <br>
Francois Gouget <fgouget@codeweavers.com><br></p>
</blockquote></div><br></div></div></div>