[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake -vs- huge projects

From: Alexandre Duret-Lutz
Subject: Re: automake -vs- huge projects
Date: Tue, 16 Dec 2003 23:33:32 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)

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

 Tom> We have to use subdir-objects
 Tom> Also, we use a single top-level
 Tom> The problem is, automake generates an explicit rule for each
 Tom> compilation.  Our resulting 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:".

Couldn't we use the (existing) .java.o: inference rule in this
case?  Actually, is there a difference between `%.o:' 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

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 vs. .java.o: choice.


Alexandre Duret-Lutz

reply via email to

[Prev in Thread] Current Thread [Next in Thread]