Mike Sullivan wrote:
> Roland Mainz wrote:
[snip]
> > Mike.Sullivan at sun.com wrote:
[snip]
> > ... which leads to a question: Shouldn't "bldenv"&co. clear the
> > environment except those env variables which are "known to be good" ?
>
> they try, though they have evolved by removing those known to be bad
> rather than just leaving those known to be good. The problem is that
> those variables change over time as things get integrated, and is
> particularly bad in sfw where we don't control most of the Makefiles.
> So things that we think of as 'good' today might not be 'good' tomorrow.
Do you have any specific examples ? The variable list in my previous
email listed those who are expected to be available in a normal Unix
login environment + X11 variables (e.g. for X11 editors) - what else
would be needed (right now I can't think about any examples) ?
> > ... question to the gatekeepers: Should I file a RFE to let "bldenv"&co.
> > clear the environment ? I would add to new options: --acceptenvvars and
> > --rejectenvvars which accept patterns (shell patter, grep pattern, egrep
> > pattern, fgrep pattern or perl pattern) to filter out environment
> > variables by name. Any variable name which does _not_ match the pattern
> > for "acceptenvvars" will be removed and any variable name which matches
> > the pattern for "rejectenvvars" will be removed, too (e.g. a traditional
> > accept/reject filter chain).
>
> there is already a bug for making nightly start off with a clean
> environment, you should probably just go fix that and then we
> never have to worry again.
Erm.. that is technically what my patch would be doing... I only provide
two additional "tuneables" so people can change the list on demand
without having to hack "bldenv" first.
> I don't really see a need to let people selectively add/subtract
> variables as that just looks like more ways to make builds differ
> or break. And if you really need to add variables to the environment
> you can already add them to the env file.
Right - but see my comment above - since requirements may evolve over
time I want to add some tuneables to adjust the filter chain on demand
(hey - it's my burden to get the filter right)
> > I already have a contribution for "bldenv" queued (CR #6600149
> > ("bldenv_cleanup")) and could easily integrate the functionality into
> > it... "nightly" would follow with a seperate CR# and putback once we
> > have positive feedback from that putback that the change worked...
>
> actually no - you need to make sure the change works before you
> putback.
I know that... however changing both "bldenv" and "nightly" is a bit
time-consuming and I prefer to handle these scripts one-by-one (CR
#6600149 is special in this case since we don't introduce new
functionality (erm... which isn't 100% true since stuff like $ bldenv
--man # will now work and boolean options now support true/false as
required by POSIX/SUS, e.g. "-d" enables debug builds, "+d" disables
debug builds again)).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
