Re: Fwd: Import statement - non-recursive make implementation

[Kamil Mierzejewski]

Hi,

Tim, your explanation of the problem is exactly what I want to deal with, and...

> Does this change sort that out so that:
> 1) all the little sub-makefiles can have paths and references that are
> relative to their location in the filesystem but:

Yes, the "solution" makes it possible. The whole point was to be able to use "Divide and rule" 
strategy in designing build process of large systems without loosing the power of parallelism, as 
the benefits of parallelism grow with the project size.

> 2) they can still all be loaded into one large make process that can
> capture cross-dependencies and build everything in parallel.

Yes, sub-makefiles can be loaded by a master makefile (recursively) using "import" directive. All 
cross-dependencies are matched.

There is also another issue that has to be dealed with - variables. Every makefile can define it's 
own variables. If we want to load a couple of makefiles, we need to ensure that no two makefiles 
modify each other's variables. That's why I used a stack of variable sets. When a makefile is 
imported, a new variable space is pushed to a stack, so the makefile defines and modifies variables 
in it's own scope. After reading an imported makefile the variable_set is popped, but it's not 
freed, because recipes defined in that makefile may use variables from it's scope - the solution 
deals with it.

Having separated variable spaces of each makefile, I define a special variable. I called it 
".FILE_SCOPE" it's the path to the imported makefile's parent directory. It's then prepended to 
every file path that is entered into make database, except for absolute paths and special targets. 
This way you can always use paths relative to makefile's location and the whole system is still 
coherent.

I also redefine CURDIR for imported makefiles to make them feel at home ;-).

All automatic file variables are expanded to paths relative to the makefile's directory, except for 
absolute paths of course.

$(shell) and $(wildcard) functions are also affected, because they have to run in the makefile's 
directory too.

An example:

./makefile:

import dir1/makefile
import dir2/makefile

main.txt:dir1/main.txt dir2/main.txt
        cat $^ >$@

------------
./dir1/makefile:

PRIVATE_VARIABLE:=I'm in dir1

main.txt:
        echo $(PRIVATE_VARIABLE) > $@

-------------
./dir2/makefile:

TARGET=main.txt
$(TARGET):
        echo Here $(PRIVATE_VARIABLE) is not defined > $@


The result of calling make in . would be sth like this:

(enter dir1)
echo I'm in dir1 >dir1/main.txt
(leave dir1)
(enter dir2)
echo Here  is not defined > dir2/main.txt
(leave dir2)
cat dir1/main.txt dir2/main.txt >main.txt

        
> Sorry - am daydreaming here. I know that a certain commercial tool
> does this in effect but I'm more interested in GNU make being able to
> do things.

I was also a dreamer, looked into the source code and came up with this.


Kamil