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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
