On Sat, Apr 7, 2012 at 9:32 AM, Steve Reinhardt <[email protected]> wrote:
>
>
> One simple thing to try would just be to have util/regress run scons
> twice, leveraging the behavior described above in #1, possibly
> filtering/sorting the output of the second run as described here. Of
> course, this approach would work best if (1) scons never spuriously
> rebuilds anything and (2) scons didn't take a long time to figure out that
> nothing needs to be rebuilt. I don't think the former problem isn't too
> bad, in practice, since even though scons does like to re-run some of the
> intermediate steps (due to that source file sorting issue that's been
> discussed in the past), it seems to recognize that the outputs haven't
> changed and thus doesn't rebuild the binary or rerun the test. At least
> that's been my experience.
>
Another alternative would be to have util/regress effectively tee the
output of the original scons run into a temp file, then do the
post-processing on that, similar to what happens in the current cron
script. Since the cron script uses util/regress, we could get rid of the
cron processing and unify the outputs, which could be nice, though I think
that ideally you want the failures at the top in an email output and at the
bottom when run interactively, so maybe that's not perfect.
The downside is that you'd still run into the multithread output
interleaving problems that we get from -j runs that occasionally mess up
the cron outputs.
For the record, here's all the processing that the cron script does. Note
that the regression script is explicitly saving the scons output in
'logfile' so we don't have to add the tee like we would in util/regress.
# Echo interesting lines to stdout
# Print failures first so they're easy to see
egrep '\*{5} .* FAILED' $logfile
# Now print other potentially bad stuff
egrep '(scons:|qdo-)' $logfile
# Now print passes (just so we know what actually got tested)
egrep '\*{5} .* passed' $logfile
Steve
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
