PATCH: Parallel compilation of class files

Thu May 9 19:34:00 GMT 2002

>>>>> "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