[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kamil Mierzejewski
Subject: Re: Fwd: Import statement - non-recursive make implementation
Date: Tue, 14 Sep 2010 09:18:44 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; pl; rv: Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3


I'll try to prepare a patch and submit it to patches list on Savannah, if anyone is interested. I am a little busy lately so it can take a while.

I commented the changes so I hope that the code will explain itself better than 
I did in previous posts.


On 2010-09-07 19:53, Tim Murphy wrote:
Why didn't you do this 4 years ago darnit? ;-)



On 7 September 2010 17:40, Kamil Mierzejewski
<address@hidden>  wrote:

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

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

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:


import dir1/makefile
import dir2/makefile

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



        echo $(PRIVATE_VARIABLE)>  $@


        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.


Bug-make mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]