Thanks Paul, and also to the others, who have responded to this idea. My problem is that contrary to the make wisdom of writing a single Makefile (to which I agree) most projects are still divided into parts with separate build definitions. One can debate if this is good or bad - for me it is a requirement to handle this case efficiently. (If you do not agree there is no point in discussing further.)
I use autotools, so I could try fixing it in automake. Automake *does* have the opportunity to compile a single Makefile.in from many distributed Makefile.am files in subdirectories. There are well-defined references between these Makefile.am files. Of course, not everything will work easily, because Makefile.am files can contain low-level Makefile content, as well and these are hard to combine (as you have pointed out in the quoted block below). But, if one assumes that the Makefile.am author restricts itself to using the high-level autotools concepts (e.g., by using only _PROGRAMS, _LIBRARIES and other automake-specific variable names), then such merging is, in fact, possible. I am not sure what percentage of the autotools projects are such. Or we could try solving this merge issue one level below by somehow merging Makefiles directly. Here comes your comment as a roadblock to that. > However, I think this will be extremely difficult, because makefile targets > are so free-form and prerequisites and targets are not actually necessary > files at all. If you're talking about the target "all", and it's redefined > in > the sub-make, you need to be sure that all references to that target in > the sub-make go to _that_ version of "all", and references to "all" in a > different make go to _those_ versions of "all". But, sometimes you do > want the parent makefile to be able to refer to the targets in the child: > sometimes you want it to be the same thing, and sometimes a different > thing. > And, you have the same problem with variables, pattern rules, etc. as well. Couldn’t these be handled by creating a "namespace" concept for rules? One could merge 2 Makefiles by prefixing each target with the directory of the Makefile. This would make dir1/all different from dir2/all. Also in recipes variables, pattern rules could be used from the Makefile describing the recipe. Would this not be possible (in theory, at least)? I simply refuse to accept (so far) that the autotools ecosystem cannot cope with this problem. Zoltan
