Right way to cope with user error in make test?

[Steven Edwards]

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
include/wine/test.h

#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.

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
test. 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. But
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 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.

-- 
Steven Edwards

"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo