Unwanted Optimizations

Mark Ellis mark.uzumati at virgin.net
Mon Apr 1 13:57:05 PST 2002

On 2002.04.01 19:54 Jesse Tie-Ten-Quee wrote:
> > With the way it is now, one can easily skip some <setenv>s and
> > perhaps execute elements after it, which depend upon it.
> Uh, skip?  What difference is it if it's inside a stage or it has it's
> own tags?  I don't see how that makes all that much more of a
> difference.
> I though the point of <stage> is to make it easier to group things.  I
> can't support such a change if i can't easily use <stage> like we are
> presently using <build> and so forth... otherwise, it's just making
> things more complicated then need be.  [however, i'll wait untill i
> see
> a good example before making a judgement on this]
> > If there are no other volunteers, I'll modify the beginning of LFS
> > profile, using the ideas mentioned on the list regarding <stage> and
> > new <package>, so we could have an example and be able to see the
> > "full picture".
> If you have the time, please do.  I've read most of the threads on
> this
> subject and so many things were said, it's just confusing me at this
> point.  It would problaby simplify things overall for everyone too ;)
> Even just like a portion of chapter 5 or something, to show if off.

Allow me to try, though be nice, i think easter has taken a toll on my 
brain :) And forgive me if i go into _really_ simplistic mode, i have 
to get it straight in my own head as i go.

Currently, <setenv> appears in profiles in a linear way, it gets 
executed when the parser reaches it, then is forgotten, just as 
<mkdir>, <copy> etc. so if you have a profile :-

<package1 />

<setenv />

<package2 />

> package3 />

if you request execution to start at package2, the setenv is not 
executed. <stage> replaces the linear model with a kind of "dependency 
tree" affair, which is probably completely the wrong term to use but i 
cant think of anything else :) So with :-

<package1 />


   <package2 />


<package3 />

if you start the profile at package2, the parser knows that since 
package2 is in the <stage> it must use that stage, and hence it sets 

Similarly, when the parser finishes everything in the stage, it exits 
it and restores the environment to its previous state, ie without FOO, 
or whatever FOO was beforehand if anything. package3 therefore does not 
have to worry about a polluted environment space.

This would also apply to setting effective user and group, which would 
also be reset after the stage exits.

In effect, <stage> elements are never them selves marked "done", 
"completed", "skip" or whatever else that will show an element as "not 
to be executed", as long as one of their children is to be run then 
<stage> is _always_ executed.

Does that make any sense ? I don't think i explained it particularly 
well but hopefully someone else can flesh out my yabberings :)

Hang on, better way of explaining it to any programmers, <stage> is a 
function call, everything it defines is a local variable, everything 
hidden by these locals is put on the stack until the function exits, at 
which point they are popped from the stack. This is in fact exactly the 
way i would implement it if we go with this idea.

Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list