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