>>>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> An aspect, I don't see how an import feature would help is Ralf> "scoping": A subdir-Makefile.am controls one subdir, a flat Ralf> toplevel Makefile controls all subdirs. I.e. when developing on Ralf> a package, with a non-flat Makefile structure, e.g. a "make Ralf> clean" inside of a subdir cleans this single subdir. With a flat Ralf> Makefile the whole source tree will be "cleaned". FWIW the original 'import' plan included support for scoping of the automake-generated rules, e.g. 'make subdir/clean'. Ralf> Yet another aspect is size/speed of files generated from Ralf> flat-Makefile.am. Processing all-flat Makefile.am of a source tree Ralf> containing 100s of source-files can be annoyingly slow and easily reach Ralf> the order of several minutes, even on contemporary HW. Ralf> I don't see how an "import feature" would help. The hope was that a single Makefile would improve performance by eliminating multiple 'make' invocations, and by allowing better parallelism across the entire project -- right now parallelism is limited to a single directory. We didn't really consider make scalability back when thinking about this. Oops. But, perhaps whatever problems there are in make are solvable there. In any case the import plan looked pretty complicated to implement. And, it would have required user support in some cases. As you noted, you can't go around rewriting make rules arbitrarily; we were thinking of adding a new '%subdir' automake-time substitution, or something like that, to let people write relocatable rules. Tom
