Re: automake -vs- huge projects

[Alexandre Duret-Lutz]

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

 >>>>>> "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.

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

 Tom> There's an old thread on this:

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

Thanks for the pointer!  Especially I'm glad to learn that there
are two more Make implementations where this works.

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

I've found this:

1999-11-22  Tom Tromey  <address@hidden>

        * automake.in (handle_single_transform_list): Generate explicit
        rule for subdir objects.  Fixes new addition to subobj.test.

Unfortunately the comment added to handle_single_transform_list
just says "Also, if we have a subdir object, we need to generate
an explicit rule" without justification, and the addition to
subobj.test is

# ... and a third bug.
grep "COMPILE.*generic/a" Makefile.in

A cursory scan of automake@ and bug-automake@ around that date
did not yield any insight.

 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.

 Tom> 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).

 Tom> Hmm, maybe this is the issue from way back.

I'm not sure about this.  In the past dependencies were put in
.deps/subdir/X.Po (i.e. where the suffix rule--at least
today--would put them).  You moved them to subdir/.deps/X.Po on
2002-01-20 for PR/224.

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

:)

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

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

I think what to do will be clearer once someone tries to get
these things working.  I may work on this, but not before
Christmas.

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

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

I confess I'm not really fond of adding a gnu-make option, since
that increases the combinatoric of all possible outputs that the
test suite ought to cover (but don't).  Sigh, if only we had a
way to generate test cases automatically...
-- 
Alexandre Duret-Lutz