<setenv>, <stage>

Lee Saferite dsaferite at internet.lu
Mon Apr 1 23:45:48 PST 2002

On Tue, 2 Apr 2002 01:02:01 +0200
Neven Has <haski at sezampro.yu> wrote:

> On Mon, Apr 01, 2002 at 11:19:43PM +0100, Mark Ellis wrote:
> > > <stage name="setup">
> > >     <env>
> > > 	<name>CPPFLAGS</name>
> > > 	<value>blahal</value>
> > >     </env>
> > > 
> > >     <configure>
> > > 	<dir>/usr/src/blah-0.1</dir>
> > > 	<option>--prefix=/usr</option>
> > >     </configure>
> > > </stage>
> > > 
> > > And it gets unset when it exit's out of this stage?  I duno, just
> > > an idea that popped into my head.
> > 
> > I think there may still be a place for <stageinfo> when setting the 
> > environment etc. just to group all the settings together, just IMHO.
> I agree. And I like the above (heh, for now, I should say ;).

Umm, I don't think mixing the 'setup' elements with the 'action'
elements is too go an idea.  Just me.  It would make sense to group ALL
the setup elements, the ones that set user, root, group, env, default
base, etc. under one element.  Then, when you use <stage> you can ignore
the <stageinfo> element if you don't need that functionality.  But if
you need to su, chroot, or setenv then you have that element present. 

   <chroot dir="/mnt/lfs">
     <su user="lfs">

           ...  The actual action elements.



<stage name="Prebuild">

   ... the actual action elements


That assumes you define <setenv> as a container.  If it's NOT a
container, it makes it impossible to start at a random element and know
that the env will be correct.  Using the stage element, the parser knows
that before it can execute a child element, like <make> or <copy>, that
it must do all the setup from all the parent containers.  That means, it
goes up the tree until it hits the root container, then it moves back
down setting user, base, root, env, etc.  Any element that is not
defined, is take from the parent container.  For example, if you define
a <base> element in the uppermost <stage> element, but not for any
children containers, then the children would use the <base> element from
their parent.  Same with the <environment> element.  It's effect/affect
is cumalitive(sp).  As long as a child chooses to "add" to the current
env then it is the sam env as the parent has.  but, when a child
container is finished, the next sibling container would not see the
changes. understand?  You need to have SOME way of doing this.  Even if
you don't decide to use <stage>.  It's a neccesity(sp) if you want to
start an element halfway through a profile/package.
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