Improving <setenv>

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


On 2002.03.21 21:26 Lee Saferite wrote:
> On Thu, 21 Mar 2002 13:26:16 -0500
> "Seth W. Klein" <sk at sethwklein.net> wrote:
> 
> > Mark Ellis <mark.uzumati at virgin.net> wrote:
> >
> > Stages would have to nest and attribute values would have to be
> > inherited.
> 
> That is what I had in mind and seems to make the most sense.
> 
> > 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.)
> 
> I would think keeping <package> would be a good thing.  It is a
> logical element for grouping.  Then you could use <stage> inside it to
> subdivide it any way you wanted.  That way, you could have an <info>
> entity with some required info on the package ie. <name>, <version>,
> <defaultbase>, possibly some sort of depenancy info.  Then the rest
> would be all stages or just naked elements (correct term?)
> 

Snip example

I'm definitely for keeping package as a distinct element, there will 
always be a use for specific functionality at the package level, 
particularly dependency info. When i eventually get around to finishing 
it :) my installation tracking will capture anything done within a 
particular <package>, and i would imagine Neven has worked on similar 
lines.

> 
> 
> As for the env seperator problem, I have very limited xml
> savoir-faire, but I would ask, can you have nested quotes in an
> attribute?
> 

Yep, thats not a problem at all, and one solution would be to put each 
assignment in quotes. Only drawback is that the assignment could 
contain quotes too, which isn't a show stopper but would require a 
lovely bit of logical gymnastics to match up the encapsulating quotes.

> An uglier option could be to have some sort of <info> element (maybe a
> differnet name) inside the stage element.  You could then have a
> series of elements that set all the needed options.  Actually, I think
> that sounds bad, and ugly...
> 
> <stage>
>    <stageinfo>
>       <name>Prebuild</name>
>       <user>lfs</user>
>       <group>lfsgroup</group>
>       <chroot>&LFS;</chroot>
>       <env mode="append">"you=me" "he=she"</env>
>    </stageinfo>
> 
>    <make>
>       ...
>    </make>
> 
>    <stage>
>       <stageinfo>
>          <name>Cleanup</name>
>       </stageinfo>
>       ...
>    </stage>
> 
>    <link>
>       ...
>    </link>
> 
> </stage>
> 
> Actually, having written the above, I think that looks nicer that my
> first suggestion.  You could make the stageinfo element a sigle
> instance only and required.  inside the stageinfo element you would
> have a required <name> element but the rest could be optional but
> unique (only one instance).
> 

This could work, and you could have repeating <setenv>s in the 
<stageinfo>, formatted like they are now but tied to that particular 
stage. If you then need to rerun something in that stage, the stage 
setup is performed again, including any <setenv>s that are tied to it.

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