>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
[...] Tom> We have to use subdir-objects [...] Tom> Also, we use a single top-level Makefile.am [...] Tom> The problem is, automake generates an explicit rule for each Tom> compilation. Our resulting Makefile.in 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: %.java". Couldn't we use the (existing) .java.o: inference rule in this case? Actually, is there a difference between `%.o: %.java' 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 work. 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 %.o:%.java vs. .java.o: choice. [...] -- Alexandre Duret-Lutz