Why didn't you do this 4 years ago darnit? ;-) Cheers,
Tim On 7 September 2010 17:40, Kamil Mierzejewski <kamil.mierzejew...@techland.pl> wrote: > 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 > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
