Jeremy White jwhite@codeweavers.com writes:
I've started playing with this, Alexandre, and I had a thought/question: why not put the tests under 'wine/tests'? I recognize the benefit of having a test immediately associated with the implementation. But, I would argue a) that not all tests are going to be specific to one dll
It seems to me that a given test should always be specific not only to a dll, but to a single or a few functions of this dll. When do you think this would not be the case?
This really goes with the dll separation strategy: Wine should no longer be viewed as a monolithic program, but more as a set of dll packages grouped in the same tar file. And at some point it could become desirable to split some dlls out of the main tree, or to have separate people maintain separate dlls independently. So I think the unit tests should be part of their respective dll.
b) by placing all the tests together, you make exporting a 'test' package to Windows simpler. c) You centralize the info and allow for good doco d) We can create and sustain a whole Windows make file hierarchy, which would be useful to a test writer in Windows.
I don't think we should maintain a Windows make hierarchy, at least not manually. If we have to ship Windows makefiles they should be generated from the Wine makefiles (or both types of makefile generated from some other source file). Asking people to keep two hierarchies in sync won't work.