Right way to cope with user error in make test?
dmitry at codeweavers.com
Sun May 18 21:02:06 CDT 2008
"Steven Edwards" <winehacker at gmail.com> wrote:
> On Sun, May 18, 2008 at 2:52 PM, Kai Blin <kai.blin at gmail.com> wrote:
>>> <dmitry at codeweavers.com> wrote:
>>> > That will make compiling tests under Windows even more cumbersome than
>>> > it is now, there is no such a thing as config.h under Windows.
>>> What are you talking about? If you use mingw or msvc to build the
>>> tests in tree there is a config.h
>> He's probably talking about a standalone build. That's what I use, at least.
>> As I do out of tree builds for wine, there's no config.h around.
> Well it would not be too hard to add to the #ifdef STANDALONE block in
> #define HAVE_FOO
> Whenever a HAVE_FOO check is added to a winetest as the standalone
> builds are always going to HAVE_FOO on windows.
How much tests do you usually build, and how often? I do it routinely
almost every day on a separate Windows machine by copying single .c
files and compiling them as standalone tests. I don't see any rationale
behind your suggestion.
> I just think its rather dumb to build tests on Wine that we know are
> going to fail. If we remove those failures and make it possible for
> everyone that compiles Wine to pass the suite for their build, then it
> will be alot easier to develop a culture where everyone runs make
Not everyone supposed to run the Wine tests, only those do who *really*
can comprehend the results and able to do something with them.
> As it stands right now, because hardly anyone can pass make
> test, no one can effectively use it to track regressions in their own
> git tree. Now this is mainly the fault of the tests themselves.
Again, the tests do not target *anyone*, target audience of Wine tests
is Wine developers who is able to cope with the results. Anyone else
should play somewhere else.
> lets say I am developing an application for Winelib that never will
> need D3D/GL and friends so I don't have the gl development libs, those
> tests are going to bomb for me, it makes more sense to just have the
> framework never run those tests on that target.
If you are deveoping a winelib application I don't think you want to run
the tests at all. I don't really matter whether the tests pass for you.
> If we are going to
> ship and allow the framework to be built in a broken state then we
> might as well just change configure and or the wine test sources to do
> an #error prama if a required library is missing and stop treating
> external libraries as soft dependencies.
It doesn't matter how hard we try to stop broken builds, there is not
way to stop creating them by an incompetent person. Same true for say
kernel builds, and any other project.
More information about the wine-devel