Re: automake -vs- huge projects

[Tom Tromey]

>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

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

My recollection is that we tried this and ran into real problems with
it.  I don't remember what they are any more.

There's an old thread on this:

  http://sources.redhat.com/ml/automake/1999-04/threads.html#00033

At this point I still believed that these suffix rules would work.  I
couldn't find the point where we changed things.

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

Yeah.  That would help us a lot, but...

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

Hmm, maybe this is the issue from way back.

We definitely want to keep dependency tracking.  This is pretty
important.

fastdep would be great, since we know we'll always be using gcc.  If
somehow dropping fastdep would get the Makefile.in to a reasonable
size, though, I'd be in favor of that.

Alternatively running sed or whatever once or twice before the
compilation isn't going to hurt as much as having a 9M Makefile.in.
So we could just do the rewrite in the suffix rule and pay the cost.

adl> Note that this issue is unrelated to the %.o:%.java vs. .java.o:
adl> choice.

Not completely, since GNU make might give us handy macros that would
let us do this transformation in-line.

Tom