Sorry - messed up the reply-to-all.
---------- Forwarded message ---------- From: Tim Murphy <tnmur...@gmail.com> 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 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 good at using lots of parallelism. This makes you think about using one huge makefile to build everything. It's inconvenient for some situations - especially for larger builds where some subcomponents are always coming or going and where one often wishes to build only one particular component (rather than the whole system) while working on it. It is also possible that not all engineers can have the entire system on their disc all at once. Then you try using include to "logically" build one large makefile from separate sub-makefiles but without having to maintain everything in one place. This is fairly reasonable but one sort of unpleasant aspect is that all your rules and recipes need to engineer all their paths to be relative to the same place. 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: 2) they can still all be loaded into one large make process that can capture cross-dependencies and build everything in parallel. 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. Regards, Tim On 7 September 2010 14:41, Paul Smith <psm...@gnu.org> wrote: > 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 definition is a little vague, and without knowing what > you're trying to accomplish it's difficult to judge your description of > the changes. > > Thanks! > > -- > ------------------------------------------------------------------------------- > Paul D. Smith <psm...@gnu.org> Find some GNU make tips at: > http://www.gnu.org http://make.mad-scientist.net > "Please remain calm...I may be mad, but I am a professional." --Mad Scientist > > > _______________________________________________ > 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/ -- 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
