[PATCH] winetest: Guess when to append the .dll extension.

[Rémi Bernon]

On 3/22/21 4:42 PM, Zebediah Figura (she/her) wrote:
> On 3/22/21 5:39 AM, Rémi Bernon wrote:
>> On 3/22/21 11:28 AM, Francois Gouget wrote:
>>> On Sun, 21 Mar 2021, Zebediah Figura (she/her) wrote:
>>>
>>>> On 3/21/21 1:11 PM, Francois Gouget wrote:
>>>>> WineTest derives the dll name from the test executable filename. 
>>>>> However
>>>>> the '.dll' extension is omitted in the executable filename. So if the
>>>>> guessed library name does not already have a three-letter extension
>>>>> (such as .ocx, .sys, etc.), assume it should have the '.dll' 
>>>>> extension.
>>>>>
>>>>> Signed-off-by: Francois Gouget <fgouget at codeweavers.com>
>>>>> ---
>>>>> This allows WineTest to retrieve the version information for
>>>>> windows.media.speech.dll.
>>>>> This is pretty ugly but at least it's a simple patch. Plus three
>>>>> letters should be enough for any library extension ;-)
>>>>> ---
>>>>>     programs/winetest/main.c | 10 +++++++++-
>>>>>     1 file changed, 9 insertions(+), 1 deletion(-)
>>>>>
>>>>
>>>> I don't know if any WinRT DLLs end in a three-letter word, but it 
>>>> seems not
>>>> implausible...
>>>>
>>>> Wouldn't it be more consistent and easier just to name the directory
>>>> "windows.media.speech.dll", and the test 
>>>> "windows.media.speech.dll_test.exe",
>>>> and then the rule everywhere becomes "if there's no dot in the name 
>>>> already,
>>>> append .dll or .exe"?
>>>
>>> That's how Rémi's patches started but then they switched to not
>>> including the trailing .dll.
>>>
>>> Compare: 
>>> https://www.winehq.org/pipermail/wine-devel/2021-March/182127.html
>>> To:      
>>> https://www.winehq.org/pipermail/wine-devel/2021-March/182686.html
>>>
>>> Apparently there was also a setupapi issue (which he fixed) but
>>> presumably there was a decision at some point to keep omitting the .dll
>>> extension (I don't see it in the mailing list archives though).
>>>
>>
>> Yes, omitting the .dll extension was done because of how differently
>> winetest computes the test executable names compared to winebuild. The
>> testbot uses (used?) the module directory name, while winebuild uses the
>> TESTDLL makefile variable (which could be different). It was easier imho
>> to just use the existing logic and not use .dll in the folder names.
>>
>> Also all other modules have an implicit .dll extension, unless otherwise
>> specified. It seemed more consistent to have the implicit .dll extension
>> for these modules too (considering that the extension is what differs
>> between the module folder and the MODULE makefile variable, not
>> something about dots in the name).
>>
>> There's also several other places where the implicit .dll is used (ntdll
>> loader code for instance, when looking for modules in the build tree,
>> which I had patches for at some point, but maybe others).
>>
> 
> That's the thing—it looks like windows.gaming.input *does* have a 
> different extension specified. Obviously we know that .input is not a 
> DLL extension (probably), but it's harder for tools (including ntdll and 
> setupapi) to be sure of that. I don't see what's wrong with explicitly 
> specifying .dll in those cases; that makes everything clear and consistent.
> 
> I just realized also that this winetest patch isn't correct as-is; we 
> have a DLL called "ksproxy.ax" (although it doesn't have any tests yet.)
> 

Well, I don't know, it's probably never going to be the case but one 
could argue that it should be possible to have a what.ever.drv module, 
with "MODULE = what.ever.drv" and "TESTDLL = what.ever.drv" in the tests 
Makefile and that it should work too.

In makedep.c we create test executable names by removing ".dll" from 
"TESTDLL", and it doesn't matter how the directory is named (the tests 
could even very well be located in a completely unrelated folder).

I think the correct fix is either to make sure the testbot 
scripts/winetest are able to make the same transformation from the 
TESTDLL variable, or change this makedep.c logic to always put the full 
dll name in the test executable name, so that the testbot/winetest can 
deduce it back from it.
-- 
Rémi Bernon <rbernon at codeweavers.com>