Improving <setenv>

Mark Ellis mark.uzumati at virgin.net
Fri Mar 22 04:18:03 PST 2002


On 2002.03.21 18:26 Seth W. Klein wrote:
> Mark Ellis <mark.uzumati at virgin.net> wrote:
> >
> > On 2002.03.21 09:28 Lee Saferite wrote:
> > > I like the idea of <chroot>, <su>, and <setenv>  but for
> simplicity
> > > (or mybe to make it more complicated)  why couldn't we have a:
> > > <stage name="Ch.5 - Installing Bash" root="/some/dir"
> user="lfsuser"
> > > group="lfs" env="E=mc2">
> > > You could use the attibute addenv to append to the env.  and you
> would
> > > have all env changes be aplicable only to elements of the stage
> tag.
> > > I mean, if you look at it, every time you do a setenv or su or
> chroot
> > > you are entering a 'stage' of the building process, no?
> > > Comments/Flames welcome.  =)
> >
> > I think i like this, it might seem messy at first 'cos you'd have to
> 
> > have most of those attributes as optional, but its versatile and
> could
> > even replace *build :) <ducks/>
> 
> <looksinnocent/> ;)
> 
> But strangely enough, i think i like it too. Lets see...
> 
> I didn't think i liked the name "stage", but on second thought, i
> think
> i do like it.
> 

Had the same reaction at first, but it sounds right now.

> Stages would have to nest and attribute values would have to be
> inherited. Example:
> <stage root="/some/dir" user="lfs">
>  ...
>  <stage user="root">
>   <!-- stage.root is "/some/dir" -->
>    ...
>  </stage>
> </stage>
> 

Yep, sounds good.

> Can this replace package then? I think it can. It would add a grouping
> element for packages, too. (I forget what that was called last time
> someone suggested it.)
> 

No, see my other reply.

Snip examples.

> 
> So i have
> <stage
>   name=""
>   version=""
>   wd="/"      <!-- working directory, hoping that someone would think
>                    of a good name 'cause i haven't -->

Do you intend this as a <base> for the whole stage ?

>   env=""      <!-- at least in my profiles, add is the common case -->
>   envclearto=<no default> <!-- and total reset rare  -->

Or maybe a flag to say clear the env space before setting it to env.

>   user=<user running the tool>
>   group=<ditto>
>   chroot=<no default>
>   role|class|etc.=  <!-- maybe something like this for *build people
>                          who just _have_ surround their elements with
>                          an extra layer ;) <ducks/> -->

  :)

> >
> 
> > Still one problem, specifying more than one env variable. A
> separation
> > character works in something like $PATH 'cos that character can
> never
> > appear in what it is separating. Everyones mission should they
> choose
> > to accept it is to think of how to separate arbitrary env var
> content
> > that can conceivably contain anything, while staying within the
> limits
> > of legal XML. I'm off to the pub :)
> 
> ~ $ cd var/tmp/
> ~/var/tmp $ echo 'echo $FOO $BAR' > echovar
> ~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO -pipe" bash
> echovar
> -march=i986 -cpu=i986 -O9 -march=i986 -cpu=i986 -pipe
> ~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR='-O9 $FOO -pipe' bash
> echovar
> -march=i986 -cpu=i986 -O9 $FOO -pipe
> ~/var/tmp $ rm echovar
> ~/var/tmp $
> 
> So maybe:
> <stage env="FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO
> -pipe"">
> Would make the life of real parser writers difficult, but they'll have
> trouble anyway because they'll need to handle PATH=$PATH:/bar (won't
> they), and everyone who just passes this stuff off to bash will have
> to problems.
> 

Sigh, pass the regex manual. This is doable, an utter pig but doable. 
Maybe it would be best to break some of this up into elements, like we 
have <setenv> now but as a specific child to <stage> ? Might even be 
better to break out some of the oher attribs into elements too. But as 
a concept this is looking better and better.

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