GSoC Idea: Tools - Winetest Scripting Interface

[Henri Verbeet]

On 6 March 2016 at 16:01, Zhenbo Li <litimetal at gmail.com> wrote:
> 2016-03-04 20:26 GMT+08:00 Henri Verbeet <hverbeet at gmail.com>:
>> On 4 March 2016 at 09:47, Zhenbo Li <litimetal at gmail.com> wrote:
>>> Alice is developing graphics driver, and wine's test for
>>> d3d(8,9,10,11) would be a great test case. She was following this
>>> workflow.
>>> 1. Edit graphics driver
>>> 2. cd /path/to/wine; cd dlls/d3dx9_36/tests; make test;
>>> 3. cd /path/to/wine; cd dlls/d3d9/tests; make test;
>>> (test other graphics related dlls)
>>> 4. Edit graphics driver again.
>>> 5. Run wine tests again, and compare them manually.
>>>
>>> With improved wine test suite, her workflow can be
>>> 1. Edit graphics driver
>>> 2. wine_test_suite --test_dll d3dx9_36 d3d9 d3d8 etc. --output result.txt
>>> 3. Edit graphics driver again
>>> 4. wine_test_suite --test_dll d3dx9_36 d3d9 d3d8 etc. --compare result.txt
>>> And the script will tell Alice whether she had introduced, or fixed a bug.
>>>
>> winetest can do this.
>>
>
> Do you mean setting the filter in winetest?
>
To stick with the example, you'd do something like
    winetest -c -t <tag> -m <email> -o result.txt d3dx9_36 d3d9 d3d8 etc.

> This sounds good. A straight approach is to scan Makefile.in, and
> generate a dependence tree from IMPORT and DELAYIMPORTS. However, I'm
> wondering how to handle the dynamic dependencies. For example, in
> dlls/mshtml/xmlhttprequest.c, we have
>     hres = CoCreateInstance(&CLSID_DOMDocument, NULL,
> CLSCTX_INPROC_SERVER, &IID_IXMLDOMDocument, (void**)&xmldoc);
> And the development for msxml really affected mshtml.dll's behavior.
>
Yeah, that would be a problem. (Provided we care about those. For
Direct3D it's generally not an issue.)