RE: new feature idea: ingesting processed rulesets

[Zoltán Turányi]

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