Hi,
I'll try to prepare a patch and submit it to patches list on Savannah, if anyone is interested. I am
a little busy lately so it can take a while.
I commented the changes so I hope that the code will explain itself better than
I did in previous posts.
Kamil
On 2010-09-07 19:53, Tim Mur
Why didn't you do this 4 years ago darnit? ;-)
Cheers,
Tim
On 7 September 2010 17:40, Kamil Mierzejewski
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 p
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 whol
> One wants to have a big build to make the most use of the parallelism
> that's available but also to deal with dependencies that span
> components or directories. A hierarchy of makefiles that run each
> other recursively can't represent these dependencies properly and also
> are not terribly go
Sorry - messed up the reply-to-all.
-- Forwarded message --
From: Tim Murphy
Date: 7 September 2010 15:12
Subject: Re: Import statement - non-recursive make implementation
To: psm...@gnu.org
Hi,
I think I can guess and if I'm wrong then please ignore this.
One wants to
On Fri, 2010-09-03 at 17:45 +0200, Kamil Mierzejewski wrote:
> I came up with a solution to this long-lasting, largely-talked problem
> of recursive make invocation.
Can you please clearly describe the problems you want to solve, then
describe the solutions you came up with?
The above problem def
Hi,
I came up with a solution to this long-lasting, largely-talked problem of recursive make invocation.
I also have a patched GNU make build that can be a live proof that it actually works.
First I thought of a smart "include" directive, that would isolate the included makefile's variable
sp
