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

[Tim Murphy]

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

Cheers,

Tim

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:
>
> 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
> 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:

http://www.thezimbabwean.co.uk/