Updated winetests.exe

[Dimitrie O. Paun]

On October 1, 2003 06:25 am, Ferenc Wagner wrote:
> "Dimitrie O. Paun" <dimi at intelliware.ca> writes:
> 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.

Well, normally we should build on official releases, as it
avoids confusion: we have well known files, etc. to refer to.
I agree with you that we should have a way to do intermediate
releases, but if we do them we should mark them somehow (that
should be easy to do). For official releases we can't just use
the current date, simply because Alexandre may do the release
at night (say 23:00, as he usually does), and we will not get
around to it until the next day. Granted, non of these are
real problems, I'm just saying we need to be careful how we
label things so we can make sense of them when we look back.


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

Even for non-official builds we should have the CVS version
of the file (IF the file was not modified in the build tree),
so we can provide cvsweb links there as well.

> Well, the trick is in the compile_file_with_* routines.  The

True. Let's reorganize things a bit:
    make -s  #build the entire tree under Linux
    for dll in $DLLS; do
        wine dlls/$dll/tests/$dll_test.exe.so
	for file in dlls/$dll/tests/*.c; do
	    ver=`cvs status $file | grep Working | awk '{print $3}'`
	    echo "  * $file $ver"
	done
    done
    for build in $BUILD_SYSTEMS; do
	echo "*** Build: $build"
	make -s $build 2>$build.errors  #don't take this to literal :)
	cat $build.errors
    done

This should be doable, and parsable, right?

> > 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??

We don't need to _ship_ different binaries. All we need to make
sure is that tests build. If we can't do that for MSVC, then
too bad, so sad -- we can't get stuck there. But there is a simple
way to do the MSVC build: AFAIK cl.exe works under Wine, so we
can have targets in the Makefiles that build with that. So what
we need is an installed MSVC, an version of Wine that is _known_
to run cl.exe just fine, and a bit of elbow grease.

But I think we are going in the wrong direction here. This is more
part of a different project, a porting status (Steven is working on
that). Maybe we should drop all this and just focus on tests results,
it doesn't make sense to track build status just for some files here,
when we're (hopefully) going to do the tracking for the entire tree.

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

For sure, that should be fairly simple, all we have to make
sure is we do a decent job with the labels.

-- 
Dimi.