<setenv>, <stage>

Mark Ellis mark.uzumati at virgin.net
Mon Apr 1 14:06:37 PST 2002


On 2002.04.01 22:37 Neven Has wrote:
> On Mon, Apr 01, 2002 at 10:54:11AM -0800, Jesse Tie-Ten-Quee wrote:
> > > I mean, the only thing where it will make a difference, is the
> above
> > > <setenv> (or <environment> inside <stage>). This is because it
> will
> > > make setting the environment a container of that environment. So
> before
> > > every element inside is executed, parser will have to go through
> > > <stage> and _then_ set the environment.
> >
> > > 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.
> 
> For example:
> 
>     <setenv> <!-- set the variable -->
>         <variable>CPPFLAGS</variable>
>         <value>-Dre_max_failures=re_max_failures2</value>
>     </setenv>
> 
>     <configure/>
> 
>     <setenv> <!-- unset the variable -->
>         <variable>CPPFLAGS</variable>
>     </setenv>
> 
> If you want to start executing from <configure>, there is no reason
> for
> <setenv> to be executed first.
> 
> It is totally independent of it, and nothing tells it that <setenv>
> might
> _needs_ to be executed first.
> 
> But if <configure> is _inside_ <setenv>, as its child, it would be
> obvious
> that it needs it.
> 
> And I'm talking XML-only here, I don't see it as an implementation
> issue,
> purely a syntax one.
> 
> > 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]
> 
> Actually, the <stage> _would_ be like <*build> elements (containers
> only). But with the variable name and additional feature - a
> possibility
> to set the environment, change root directory and change user IDs.
> 
> > 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 probably simplify things overall for everyone too
> ;)
> >
> > Even just like a portion of chapter 5 or something, to show if off.
> 
> Hm, this is messy. There are too many <stage>s everywhere and soooo
> many
> nesting levels. I find it very hard to read. And I wrote it myself. ;)
> 
> I have added <stage>s wherever <*build> elements used to be. Also,
> "stageInfo" and "packageInfo" are used. I haven't modified other
> elements.
> 
> I have also attached a quick'n'dirty patch against nALFS-1.0.2,
> as an example of how it would look ("*Info" elements should probably
> be removed from the output). But this is more like "for fun" - we
> shouldn't consider this when talking about syntax.
> 
> Anyway, after writing this, I'm not sure about <stage> any more. :/
> 
> It's hard to see what the stage really is - you have to find a
> stageInfo,
> then search for name and finally read it. Simple elements that
> describe
> themselves (<build>, <chroot> and others) make a profile much easier
> for
> reading.
> 

I see what you mean, but i still like the idea. Maybe it would improve 
readability to have the stage name as an attribute, it would then be 
more obviously attached to that particular stage ? Still keep all the 
other stuff in <stageinfo>. Or maybe it just shouldn't be a replacement 
for the *build stuff, but instead used specifically for modifying the 
environment, and i use environment in its broad term, including user 
and group as well as variables ?

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