automake -vs- huge projects

[Tom Tromey]

Tom Fitzsimmons (CCd) has been working on upgrading libgcj to use
newer auto* tools.  This has gone swimmingly, except one problem with
automake.

A little background.  libgcj is pretty big.  It has 2,243 ".java"
files at the moment.  Previously it has been using its own slightly
hacked automake 1.4.  It used to use its own "%" rules to handle
compiling .java (since 1.4 couldn't do this).  It is part of GCC,
which recently decided as a project that requiring GNU make is ok.


We have to use subdir-objects, both because nobody wants 2000 .o
files in "." and because we have unavoidable basename clashes between
.java files.

Also, we use a single top-level Makefile.am, as it is way more
convenient.

The problem is, automake generates an explicit rule for each
compilation.  Our resulting Makefile.in is nearly 9 megabytes.  This
is really much too large -- compare to 200K with automake 1.4.


One idea we had for a fix is to introduce a new "gnu-make" option that
would allow automake to generate code relying on GNU make.  Then we
could replace all those rules with a single "%.o: %.java".

I thought this probably wouldn't be a popular idea, but figured I'd
send it past you just in case.  We definitely don't want to have a
local fork of automake any more -- it is too much of a pain, and GCC
as a whole is trying to update and standardize on one set of tools for
the whole tree.

Any other ideas for how to fix this problem?

In absence of a real fix, another option for us is to just hand-write
our Makefile.  I'd really rather not do that, either.  Though I
suppose if we start from Automake's output it won't be too awful -- we
can still preserve dependency tracking and the like.  The long term
maintenance on this is likely to be hard though.

Tom