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