>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
>>>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> * 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