Unwanted Optimizations

Jesse Tie-Ten-Quee highos at linuxfromscratch.org
Mon Apr 1 15:22:24 PST 2002


Yo,

On Mon, Apr 01, 2002 at 10:57:05PM +0100, Mark Ellis wrote:
> 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.

Heh.  I feel terrible right now, i had planned on responding to all the
posts and updating syntax.txt with all the suggestions and such, but
after last weekend, whaaa.. i don't think that's going to happen
tonight =/

> 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 
> FOO.

IC, so it's "smart".  It doesn't exactly start at package2, but looks to
see first if there's a <stage> tag as it's parents and does whatever it
specifies?  This does make alot more sense.

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

I've noticed the user of stuff like <dir>/<base> in <stageinfo> before.
What happens if stuff like relative paths come into play then?  I guess
like you mentioned, if you want to "skip" to a part in the profile, the
impl would have to go through all the <stage> tags to make sure the
environment is proper, no?

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

That's alot better then what i've previously read.  Well, in terms of
making a quick description ;)

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

nods.  Neato.

-- 
Jesse Tie-Ten-Quee  ( highos at linuxfromscratch dot org )
-- 
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