[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake -vs- huge projects
Re: automake -vs- huge projects
Wed, 17 Dec 2003 10:47:16 +0100
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (gnu/linux)
>>> "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:
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
# ... 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> 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
adl> Note that this issue is unrelated to the %.o:%.java vs. .java.o:
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...
Re: automake -vs- huge projects, Alexandre Duret-Lutz, 2003/12/16
Message not availableRe: automake -vs- huge projects (1st patch), Alexandre Duret-Lutz, 2003/12/27
Re: automake -vs- huge projects (1st patch), Thomas Fitzsimmons, 2003/12/30
Re: automake -vs- huge projects (1st patch), Alexandre Duret-Lutz, 2003/12/30
Re: automake -vs- huge projects, Ralf Corsepius, 2003/12/18