On Mon, 15 Apr 2019, Zebediah Figura wrote: [...]
This is a little confusing. w2008s64 doesn't ship qedit, and winetest accordingly doesn't run it. Shouldn't the TestBot also skip it?
That's because WineTest uses the executable's filename to guess which dll is being tested and check whether it is present.
But that does not work for the TestBot since the user can upload executables with arbitrary names. So the TestBot's TestLauncher (which replaces WineTest.exe) grabs the list of dlls that the executable links with and checks whether they are present.
But qedit_test.exe does not link with qedit.dll since it's all COM. So all looks fine and TestLauncher runs the test.
I see. What do you recommend as the solution to this problem?
Here are some options:
1. Modify TestLauncher.exe to do things like WineTest.exe and if the filename looks like xxx_test.exe, refuse to run it if xxx.dll cannot be loaded. But then we run the risk of not being able to run my_test.exe.
2. Do the above only if TestLauncher is given a specific argument which would only be used for executables compiled by the TestBot from a patch, meaning when we know that xxx really is a dll name.
The problem with 1 and 2 is that we are going to run into the same problem as WineTest.exe, which is that it sometimes fails to run tests that it should have been running because it fails to load the tested dll.
Bug 43052 - WineTest does not run the vcomp tests https://bugs.winehq.org/show_bug.cgi?id=45032
Which was initially a TestLauncher issue: Bug 31609 - TestLauncher says a required DLL is missing, but the test runs fine without TestLauncher https://bugs.winehq.org/show_bug.cgi?id=31609#c6
3. Detect if the qedit functionality is present and win_skip() if not. I don't know the best way to check if the qedit functionality is present. Check a landmark QueryInterface() result? Manually check the registry? COM being quite widespread it feels like we should probably have a standard way of doing this type of check.
But I'm certainly not excluding other approaches.