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.
PRIVATE_VARIABLE:=I'm in dir1
echo $(PRIVATE_VARIABLE)> $@
echo Here $(PRIVATE_VARIABLE) is not defined> $@
The result of calling make in . would be sth like this:
echo I'm in dir1>dir1/main.txt
echo Here is not defined> dir2/main.txt
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
I was also a dreamer, looked into the source code and came up with this.
Bug-make mailing list