[Top][All Lists]

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

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

From: Tim Murphy
Subject: Re: Fwd: Import statement - non-recursive make implementation
Date: Tue, 7 Sep 2010 18:53:51 +0100

Why didn't you do this 4 years ago darnit? ;-)



On 7 September 2010 17:40, Kamil Mierzejewski
<address@hidden> 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:
> 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
> address@hidden
> 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:


reply via email to

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