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
