[RFT/RFA] Per-directory libjava builds (take 3)

[David Daney]

Kelley Cook wrote:
> Paolo, this looks very promising.
> 
> It brings up a thought: it seems that fixing all of this eliminate the
> whole reason for the libgcj0_convenience library hack which recaused
> the long command length regression shown in PR bootstrap/20155.  Of
> course that hack was just put in place to get around another hack for a
> long command line in PR bootstrap/17222.
> 
> More specifically, this hunk:
> 
> 
>>libgcj0_convenience_la_SOURCES = prims.cc jni.cc exception.cc
> 
> stacktrace.cc \
> 
>>    link.cc defineclass.cc interpret.cc verify.cc \
>>-    $(nat_source_files) $(math_c_source_files) $(java_source_files)
> 
> \
> 
>>-
.
.
.
> 
> 
> would be converted back to referring directly to libgcj_la. 
> Effectively reverting this patch
> 
> 2005-02-15  Richard Henderson  <rth@redhat.com <mailto:rth@redhat.com>>
> 
>        * Makefile.am (libgcj_la_SOURCES): Move all sources ...
>        (libgcj0_convenience_la_SOURCES): ... here.
>        (libgcj_la_LIBADD): Add libgcj0_convenience.la.
>        (libgcj_la_DEPENDENCIES): Include libgcj_la_LIBADD.
>        * Makefile.in: Regenerate.
> 
> 
> Unfortunately, I don't have a Alpha or MIPS host to test this theory
> on.

I don't have time to test the MIPS build with this right now, and I have 
not really been following this patch.

This said, as long as we are not doing incremental linking MIPS should 
be fine. (Assuming there is no GOT overflow with in the individual .o 
files).

If there is a GOT overflow in the individual .o, we should have a way to 
break the groups of .java files into smaller groups.

David Daney.