svn commit: r258848 - user/hrs/releng/release

Hiroki Sato hrs at
Mon Dec 2 15:54:28 UTC 2013

Glen Barber <gjb at> wrote
  in <20131202152054.GH1839 at>:

gj> On Tue, Dec 03, 2013 at 12:16:28AM +0900, Hiroki Sato wrote:
gj> >  Everything can be overridden by a configuration file regardless of
gj> >  whether envvars are honored even after this change.  What is the
gj> >  problem?  I do not see negative effect assuming a conf file is used.
gj> >
gj> This allows the host environment to accidentally pollute the build if
gj> something is not set in configuration file and unintentionally set in
gj> the builder's environment.
gj> It was why I specifically did not allow the environment to affect the
gj> build process.

 That problem is not solved by forcing variable assignments for the
 following two reasons:

 - A case that "something is not set in configuration file" can still
   cause unexpected failures because does not always set
   the reasonable default values.  A powerpc64 build fails, for

 - In the current, variables unintentionally set in the
   builder's environment still pollutes commands which run in when the variables are not set in the script but
   accepted by make or other utilities.  Catching all of the variables
   is quite difficult.

 So, clearing the envvars before running the script is needed even for
 the current to solve the problem.  "env -i" does it.  It
 is not unrealistic to assume that we can eliminate variables which
 are set unexpectedly.

 Anyway, I do not have a strong opinion if using FOO=A or : ${FOO:=A}.
 I agree that the latter assumes all of the envvars must be under
 control and it needs one more step than just invoking the script, and
 a leaked variable can break the build.  If you do not like it, I will
 change them with FOO=A.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <>

More information about the svn-src-user mailing list