idea for <stage><environment>

James Robertson jwrober at linuxfromscratch.org
Thu Jul 7 08:27:55 PDT 2005


Mark Ellis wrote:
> On Tue, 2005-07-05 at 08:05 -0500, James Robertson wrote:
> 
>>Mark Ellis wrote:
>>
>>>I noticed something in the archives from a few months ago about clearing
>>>the environment on entering a stage. The suggested solution with nALFS
>>>was to use a dummy value to <root>, eg /, which as a side effect clears
>>>the environment.
>>>
>>>A better solution would seem to be a mode attribute setting on
>>><environment> of 'clear'. Incidentally, I dont understand the current
>>>use of mode on environment as append|prepend. The variable elements have
>>>this use of mode, which makes more sense anyway, is this duplication
>>>necessary ?
>>>
>>>Ta
>>>Mark
>>>
>>>
>>
>>I don't know about the root/clear thing, but the <environment> element 
>>is designed to allow you to manipulate the running environment of the 
>>tool and the shell commands the tools runs.  The append and prepend mode 
>>options allows you to take an existing env var and fully manipulate it. 
>>  The DTD doc uses LDFLAGS. Another example is PATH.
>>
>>James
>>
> 
> 
> Manipulating individual variables is set up quite nicely, but we
> currently have no standard way to replicate LFS' use of "env -i" to get
> a clean environment. Setting all the existing variables to empty will
> work, but requires modification of the profile to each unique build
> environment.
> 
> I would envisage something like this.
> 
> <stage name="foobar">
>     <stageinfo>
>         <environment mode="clear>
>             <variable name="PATH">/tools/bin:/usr/bin:/bin</variable>
>         </ebvironment>
>     </stageinfo>
> ....
> </stage>
> 
> which would first unset every variable, then set PATH to the specified
> value, no worrying about possible LDFLAGS, CFLAGS, LD_LIBRARY_PATH etc
> polluting the build.
> 
> The default would be to keep the current environment of course.
> 
> Make sense ?
> 
> Mark
> 
> 
> 
> 
Yea, that makes sense.  We have to change the DTD to support that.  I 
would expect that with us wanting to work on alfs (the replacement to 
nALFS) that DTD changes would be in order.  But a bug in BZ for a reminder.

James

-- 
James Robertson -- jwrober at linuxfromscratch dot org
Reg. Linux User -- #160424 -- http://counter.li.org
Reg. LFS User   -- #6981   -- http://www.linuxfromscratch.org
LFS Bugzilla Maintainer    -- http://{blfs-}bugs.linuxfromscratch.org



More information about the alfs-discuss mailing list