regsvr32/tests: Add initial tests

Hugh McMaster hugh.mcmaster at outlook.com
Wed Jan 13 01:15:12 CST 2016


On Tue, 12 Jan 2016 12:58:59 +0100, Francois Gouget wrote:
> On Tue, 12 Jan 2016, Hugh McMaster wrote:
> [...]
>> diff --git a/programs/regsvr32/tests/Makefile.in b/programs/regsvr32/tests/Makefile.in
>> new file mode 100644
>> index 0000000..61d25fe
>> --- /dev/null
>> +++ b/programs/regsvr32/tests/Makefile.in
> [...]
>> +ifneq (,$(filter crosstest mingw,$(MAKECMDGOALS) $(findstring mingw,$(CC))))
>> +  TARGET_DLLS = $(addsuffix .dll, $(DLL_BASENAMES))
> 
> I believe the syntax on these last two lines is specific to GNU make 
> which is something that Wine has tried to avoid so far.

The GNU make manual doesn't list 'filter', 'findstring' or 'addsuffix' in its comparison with BSD's (p)make,
so I'm not sure about those functions being specific or not.

> Note that more generally getting a dll into this test will be pretty 
> tricky. Would it be possible to do the tests using an existing dll?

The makefile already creates the required DLL. Eventually, I'll need to use three DLLs, although
fortunately I can use the same .c source.

My preference would be to only use mingw32, but I don't think the mingw32 package is a
build-dependency for Wine. How likely is it that users building from source will have
mingw32-w64 (or equivalent) installed?

I can't use an existing DLL because I need to know exactly what happens in the DLL* functions,
so that I can test against that behaviour.

> Alternatively would it work to add the test's dll to dlls/ and 
> grab and include it as a resource in programs/regsvr32/tests? 
> This may help avoid makefile shenanigans.

I quite like this idea. I could probably use a subfolder of the regsvr32/tests, although I'd need to work
out a better method of building the .dll file, as we obviously only build .so files.

The existing code embeds the test DLLs in a resource file. The difficulty is whether to build two
resource files (one for Wine, the other for Windows), or add the resource to .PHONY and have it
rebuilt for each target.

>> diff --git a/programs/regsvr32/tests/regsvr32.c b/programs/regsvr32/tests/regsvr32.c
>> new file mode 100644
>> index 0000000..746c81f
>> --- /dev/null
>> +++ b/programs/regsvr32/tests/regsvr32.c
> [...]
>> +#define run_test(...) run_test_(output, &r, __VA_ARGS__)
> 
> A macro with a variable argument list? That does not seem portable (or 
> maybe is a> C99 feature).

It is a C99 feature. We already use it in comctl32/tests, xaudio2_7/tests, the Mac driver and wine/debug.h.

>> +static BOOL __cdecl run_test_(char *output, DWORD *r, const char *fmt, ...)
>> +{
>> +   __ms_va_list va_args;
> 
> Shouldn't this be using something like __winetest_va_list?
> To be checked...

I have no idea. __winetest_va_list is not used in the source tree at all.

>> +#define CMP(s) !strcmp(output, s)
> 
> This macro is totally unnecessary.

Yes, you're right. I'll define a new macro re-using the string in the ok() test.

Thanks for the review.

--
Hugh McMaster
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160113/0629b26e/attachment-0001.html>


More information about the wine-devel mailing list