On 2/23/03 10:25 AM, "Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
[SNIP]
>
> While you say it "tinderbox", currently the reports are really
> suboptimal. Some are red (stating not even parrot was built), but only
> have failing tests, sometimes the error reason is not show in the brief
> log, making it a PITA to read the full log (on my 64Kbit ISDN line).
I'll try to improve the brief log. The problem is that the client does not
generate this log, it's automatically generated by the server, but I can
hack around this. As for redness that should really be yellow, that's an
error in the regexp's client config file. I'll try to make them a little
more robust by default.
>
> So to make tinderboxen really more useful, they would need some improvement:
>
> 1) sync with CVS
> Currently tinderboxen seem to delete the whole tree and start from
> scratch. This generates a lot of traffic (albeit - thanks - not mine),
> but this is IMHO not necessary:
>
> $ cvs -z3 update [-d...] -dP parrot >$FULL_LOG 2>&1 &&
> perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
> make distclean ...
>
> With appropriate error checking should do it.
> Make normal entry in brief log is something like
> echo "Parrot sync src ok" > $BRIEF_LOG
This was something that original versions of tinderclient did, but I added
the unlink because it was causing trees to become corrupted. I'll probably
add this as an option in the next version defaulting to not unlink the tree.
>
> 2) building parrot
>
> $ perl Configure.pl [--options] >> $FULL_LOG 2>&1 &&
> make -s > $BUILD_LOG 2>&1
>
> - [/me dreaming:] Filter $BUILDLOG to contain the first warning of some
> type and then only a repeat count and may be maximal 1 line per
> occurance of this warning, by deleting the line number and run the
> output through some kind of "sort|uniq". The error parser of your
> $EDITOR should contain the necessary regexen to get the real
> warning/error message even from the normally multiline mess{,age}.
>
> - show all errors
> - append status to $BRIEF_LOG and $FULL_LOG
This would be good to have, but again, the client only generates the full
log and sends it to the server, but I'll see.
>
> If this fails stop here.
>
> 3) building imcc
>
> $ cd languages/imcc
> $ make -s > ...
> $ cd -
>
> Same procedure as above - but *don't stop* if this fails, only generate
> report.
This is doable, I could have it give a yellow "test failed" condition if it
fails.
>
> 4) run parrot tests (if 2) succeeded)
>
> $ make quickfulltest
>
> This runs normal, -j, -P, and -g i.e. all major cores.
I'll change this in the default config.
>
> In case of test failure show enough lines in the brief log, to really
> get the start of the problem. This is one line after the last running
> test. The output of the test (expected/got) is normally not of much
> value, but could be included e.g. as a diff.
This would also be fixed by fixing the server's brief log generation code.
>
> 5) if imcc did build ok:
>
> $ cd languages/imcc
> $ make test
>
> Summary:
> The brief log should really contain all kinds of problems but reall be
> *brief* and the full log would be just a check, that brief log is ok.
Thanks for your feedback. I'm pretty busy now, but I'll try to get the
client side of this done at least, the server side will bit a bit harder.
Zach
>
> my 2¢ & TIA,
> leo
>
