Tom Fitzsimmons (CCd) has been working on upgrading libgcj to use newer auto* tools. This has gone swimmingly, except one problem with automake.
A little background. libgcj is pretty big. It has 2,243 ".java" files at the moment. Previously it has been using its own slightly hacked automake 1.4. It used to use its own "%" rules to handle compiling .java (since 1.4 couldn't do this). It is part of GCC, which recently decided as a project that requiring GNU make is ok. We have to use subdir-objects, both because nobody wants 2000 .o files in "." and because we have unavoidable basename clashes between .java files. Also, we use a single top-level Makefile.am, as it is way more convenient. The problem is, automake generates an explicit rule for each compilation. Our resulting Makefile.in is nearly 9 megabytes. This is really much too large -- compare to 200K with automake 1.4. One idea we had for a fix is to introduce a new "gnu-make" option that would allow automake to generate code relying on GNU make. Then we could replace all those rules with a single "%.o: %.java". I thought this probably wouldn't be a popular idea, but figured I'd send it past you just in case. We definitely don't want to have a local fork of automake any more -- it is too much of a pain, and GCC as a whole is trying to update and standardize on one set of tools for the whole tree. Any other ideas for how to fix this problem? In absence of a real fix, another option for us is to just hand-write our Makefile. I'd really rather not do that, either. Though I suppose if we start from Automake's output it won't be too awful -- we can still preserve dependency tracking and the like. The long term maintenance on this is likely to be hard though. Tom