Re: automake -vs- huge projects

[Alexandre Duret-Lutz]

>>> "Tom" == Tom Tromey <address@hidden> writes:

[...]
 Tom> We have to use subdir-objects
[...]
 Tom> Also, we use a single top-level Makefile.am
[...]
 Tom> The problem is, automake generates an explicit rule for each
 Tom> compilation.  Our resulting Makefile.in is nearly 9 megabytes.  This
 Tom> is really much too large -- compare to 200K with automake 1.4.

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

Couldn't we use the (existing) .java.o: inference rule in this
case?  Actually, is there a difference between `%.o: %.java' and
`.java.o:' beside portability?  -- I'm not asking about the
general % construction, just about this precise case where both
sides are expected to be in the same directory.

I've done some limited testing (with GNU make, BSD make,
OSF1/Tru64 Make, and HP-UX make) and .src.dest: rules appear to
work for files in subdirectory even in VPATH configurations.  I
wonder if there are Make implementations where this does not
work.

So the simplest part of the fix would be to disable the output
of explicit rule for subdirectory sources without per-target
flags when subdir-objects is used.

The other side of the coin is that dependency tracking will not
work anymore, because the dependency stuff for subdir/X.o should
go into subdir/.deps/X.Po but the default suffix rule will put
it in ./.deps/subdir/X.Po.  I don't see an easy way to fix this,
unless we add some clumsy shell computation in the suffix rules
(while this can probably be folded into depcomp when it is used,
it does not seem to fit well in fastdep rules).  Note that this
issue is unrelated to the %.o:%.java vs. .java.o: choice.

[...]

-- 
Alexandre Duret-Lutz