discuss-gnustep
[Top][All Lists]
Advanced

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

Re: non recursive makefiles


From: MJ Ray
Subject: Re: non recursive makefiles
Date: 13 Jan 2005 17:58:36 GMT

As Nicola has not much time, I trim severely.

Nicola Pero <nicola@brainstorm.co.uk> wrote:
> Well, having read the rest of your email including the conclusion that you
> think that the design is obviously all wrong and you know better makes
> this initial captatio benevolentiae sound a bit flaky. [...]

I speak a few languages, but not that one. What does that mean? I suspect
you are questioning my sincerity.  My conclusions to emails have said
that the design was sound, not all wrong, but the recursion seems to
conflict with make. Are you confusing my emails with others?

> > What is the Master idea? Why can't we set the environment and then exec
> > the user's preferred shell again instead of sourcing GNUstep.sh? Those
> > are probably obvious questions and I didn't find answers.
> Because every GNUmakefile starts with
> include $(GNUSTEP_MAKFEILES)/common.make
> and unless GNUSTEP_MAKEFILES is already set in the shell [...]

I think this is in reply to the "why can't we set ..." question.
I know the environment needs setting, but why use source (and require
all users to have a Bourne or C shell) instead of a program that sets
the environment and then execs the user's preferred shell?

What is the Master idea?

> > According to its manual, GNU make "constructs a dependency graph of all
> > the targets and their prerequisites." To that graph, the above situation
> > needs to look like the final stage of building the files *depends
> > on* having completed the previous stage for all files. Why can't that
> > dependency be declared, rather than relying on implicit execution order
> > in the version of make used?
> 
> I'm not sure what you mean, to "generate the dependency graph" you need to
> have make parse and process the makefile fragment describing the rules
> (which is what I mean by "executing the rules") multiple times, each for
> every end target you want to build.  And every end target needs to get
> customized rules for that target.  More customized than you seem to think,
> you clearly haven't realized the complexity of building something like a
> framework.

Maybe not, but is there an explanation of the complexity of building
something like a framework for people like me to read? It is surprising
that what looks like a straightforward problem is so complicated.

"Executing the rules" saddens me. Make is not a scripting language.

[...]
> Ever tried to build a framework ?

Yes, but I've never written a build system for one.

[...]
> It encourages you because there are problems that have no other solution
> than to use recursive invocations.
> 
> make doesn't support iteration, so you end up with recursion.

I have tried to explain the concept of doing the iteration case you
presented without calling make in subdirectories. I am disappointed you
don't seem interested enough to explore it.

-- 
MJR/slef



reply via email to

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