On 6 March 2016 at 16:01, Zhenbo Li litimetal@gmail.com wrote:
2016-03-04 20:26 GMT+08:00 Henri Verbeet hverbeet@gmail.com:
On 4 March 2016 at 09:47, Zhenbo Li litimetal@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.
- Edit graphics driver
- cd /path/to/wine; cd dlls/d3dx9_36/tests; make test;
- 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
- Edit graphics driver
- wine_test_suite --test_dll d3dx9_36 d3d9 d3d8 etc. --output result.txt
- Edit graphics driver again
- 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.)