Updated winetests.exe

[Ferenc Wagner]

"Dimitrie O. Paun" <dimi at intelliware.ca> writes:

> On Tue, 30 Sep 2003, Ferenc Wagner wrote:
>
>> I thought the build tag (which can be any one-line string)
>> was enough.  Why do we need anything else?
>
> That works nicely IF Jakob builds the tests only on official
> releases

Why?  The current simple scheme of setting it to the date
should work if we do not build twice in 24 hours.  If that
is not enough, we can include a full CVS time specification
down to seconds, as I said, it is a simple tag, not parsed,
not used for anything except matching.

> (which should happen anyway).

Why, again?

> In fact, the build script can be smart enough to notice if
> we're not using an offcial release, and provide a
> different build tag.

Yes, it should include the full CVS date then, not a big
deal.  Yeah, when summarizing an offical release, I can
provide LXR links as an extra.

>>>   -- a simple to generate format would be: [...]
>
> It can't be that hard: we mainly have to
>    for dll in $DLLS
>       echo "*** $dll"
>       ver=`cvs status $file | grep Working | awk '{print $3}'`
>       for file in dlls/$dll/tests
>           echo "  * $file $ver"
> 	  echo "MinGW:"
> 	  compile_file_with_MinGW
> 	  echo "MSVC:"
> 	  compile_file_with_MSVC
>       done
>       wine dlls/$dll/tests/$dll_test.exe.so
>    done

Well, the trick is in the compile_file_with_* routines.  The
MinGW way is specified in the Makefiles, how would you
incorporate them?  The MSVC way is in the .dsp-s, which is
even worse.  Then you can not invoke $dll_test.exe.so,
because MinGW results in $dll_crosstest.exe while MSVC in
something else again.  One more thing, although the present
build system ensures (AFAICT) that every .c file corresponds
to a test, it may not forever be the case.  And errors are
more frequent in the linking phase anyway.

So, what I find reasonable is capturing the whole make
output in a file for every unit, and publishing it on the
condition that the make fails.  It would be easy for MinGW
and possibly impossible for MSVC, I do not have a clue about
that.  Sad to say this.  Also this is the reason I mentioned
tar.  Not for the reports, but for the master files, which
could avoid the mailing list anyway.  To be honest, I fail
to see the point of the mailing list.  These reports are
rather unsuitable for human consumption (strictly IMO).

> we really need to automate the build procedure, I don't
> think manual stuff will cut it.

Can do with MinGW, for sure.  But for MSVC??

> In fact, the build procedure should be included in our
> makefiles, and we can invoke it automatically on a new
> Wine release through the make_release script...

Fine vision, I am sold on it, although I would like to
provide a way to make more frequent builds.

Feri.