Re: PATCH: Parallel compilation of class files

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> Unfortunately this patch has caused a pretty bad build-time
Bryce> regression for libjava.

I noticed this too.

Bryce> Secondly the gcjh header generation no longer waits until
Bryce> libgcj.jar is complete, which makes this step much slower also
Bryce> because gcjh must also resolve parse source files rather than
Bryce> much faster class files.

gcjh actually can't read source files.  It only can read .class files.

Also, when doing a rebuild I saw this:

../../gcc/gcjh -classpath '' -bootclasspath . ../../../gcc/libjava/java/lang/Class
../../../gcc/libjava/java/lang/Class: no such class

This is bad.  If we somehow managed to generate Class.h then it would
cause the build to fail (we used to get a lot of bug reports about
this).

Bryce> I'm not sure how to fix this without reverting the patch. Any
Bryce> ideas?  Ideally we will just run gcj once to build all the
Bryce> class files (and have it figure out the dependencies), but gcj
Bryce> can't do that yet.

Actually, I think it can if we make a few minor source tweaks (well, I
don't think it knows how to do the java-style dependency checking --
is that what you meant?).  We can even import them from Classpath; I
believe Mark Wielaard noted all the changes required in the source.

I wonder if building by package would be the best tradeoff between
build-from-scratch speed, parallelizability (or p15y, as I like to
call it :-), and rebuild-after-a-change speed.

Tom