This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Should we remove java from the default bootstrap languages?
On 6/22/08, Ian Lance Taylor <iant@google.com> wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
>
> > On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
> >> On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
> >> > On Sat, Jun 21, 2008 at 05:21, Andrew Haley <aph@redhat.com> wrote:
> >> And for make -k check:
> >>
> >> -j1 2h18
> >> -j2 1h11
> >> -j4 0h55
> >> -j6 0h44
> >
> > For make check, it would perhaps help to split the langest runtest.exp
> > invocations (primarily check-gcc, maybe check-fortran and check-libstdc++-v3)
> > into two parts, so that make could schedule them concurrently with higher
> > make -jN -k check (e.g. for check-gcc run dg.exp in check-gcc-dg goal,
> > all the ohter *.exp's in check-gcc-other and check-gcc: check-gcc-dg check-gcc-other).
>
> I think it would only be a few days of work for somebody familiar with
> Tcl to add -j support to DejaGNU. I think that would be a very useful
> contribution to gcc development.
I had looked into this when I first was confronted with the insane
amount of time required to test on a Windows platform (mostly due to
the overhead of ssh/sftp). The biggest downside was that each
invocation of expect writes to a separate log file.
So for instance, if you invoke "make check-gcc" from the top level
makefile, this will spawn: check-gcc, check-fortran, check-objc,
check-c++, and check-libstdc++-v3 for the default Win64 target. Each
make target has its own sum/log file, and make parallelizes at that
level.
If you were to have make break that up, you would have then an
additional set of sum/log files for every check-* make target. If you
instead try to have expect break things up or parallelize a single
check-* target, you then have to deal with a sum file that is out of
order compared to any other run, and a log file at best that's just as
out-of-order, and at worst that has all of the output from the various
parallel tasks running into each other.
Now what you could do (though I don't know how "hackey" it is) would
be to run each .exp file separately and run a script to combine the
results after the fact and create a new table of results data and new
sum/log files. I was working on doing that, and was deciding on awk
or perl as the language of choice to do such a thing. We can already
specify via RUNTESTFLAGS a single exp file (and actually, a single
test in a single exp file) to run. We could just do (pseudocode
example) expect file1.exp > out1.txt &; expect file2.exp > out2.txt &;
etc...
That would then allow multiple invocations of expect that would each
write to their own sum/logs. Then at the end, you have to combine
them all so as to not be so untidy as to have tons of sum/log sets.
Combining them isn't a hugely difficult task. It's just tedious when
you aren't that advanced at scripting.