On 6 March 2016 at 16:01, Zhenbo Li <litimetal(a)gmail.com> wrote:
2016-03-04 20:26 GMT+08:00 Henri Verbeet <hverbeet(a)gmail.com>:
On 4 March 2016 at 09:47, Zhenbo Li <litimetal(a)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.)