Updated winetests.exe

[Dimitrie O. Paun]

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 (which should happen anyway). I guess we can hope
not to do some silly things. 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. Anyway, it's cool.

> >   -- you have to be able to deal (how?) with tests results
> >      that arrive before the master file.
> 
> This is impossible, I would reject them.

It's not really impossible (the way email gets delivered),
but I guess should be rare enough that rejecting is OK.

> >   -- a simple to generate format would be: [...]
> >
> > KEY:<the uuid>
> > *** <dll> (section repeated for each DLL)
> >   * <dlls/<dll>/tests/file.c>:<CVS version>  (multiple times, for each file)
> >     <any errors/warnings generated during compilation, verbatim>
> >
> > <output of 'wine dlls/<dll>/tests/<dll>_test.exe.so>
> 
> In general, this sounds almost OK, although I do not see why
> it would be simple to generate. 

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

> We should accomodate both
> MSVC and MinGW, right?  Their outputs are different. 

Sure, we can do that, we just need a line that have a
tag like so
<build_system>:
separating the output of various build systems.

> And some asterisks might be useful to separate the compiler and
> test output.

We don't need any, the output looks like this:
[dimi at dimi wine.build]$ wine dlls/kernel/tests/kernel32_test.exe.so
Usage: dlls/kernel/tests/kernel32_test.exe.so test_name

Valid test names:
    alloc
    atom
    ...

In fact, it's probably better to include this first, instead of
the '*** <dll>' line, it tells us even more info... 

> But I think it is rather hard (Jakob?) and not sure whether
> it is worth the effort.  Apart from the compiler output
> everything can be generated from the build tree (and I have
> the shell script for that), and since the build procedure is
> not automated, Jakob could simply copy some relevant output
> into dsound.dll.txt, possibly add some comments, tar it up
> with the master file and send it to WinHQ.

Come one, it's not that big a deal. Besides, we really need
to automate the build procedure, I don't think manual stuff
will cut it. Also, I don't like the tar idea, I'd like to
be able to see the reports in the emails, rather than save
a file, extract, etc. Plain text works best here.

We do spend a bit more time now working out the nits, but
I hope that at the end of the day, we can simply 
"fire and forget", with virtually no manual intervention
required. 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...

-- 
Dimi.