svn commit: r258848 - user/hrs/releng/release
Hiroki Sato
hrs at FreeBSD.org
Mon Dec 2 17:15:25 UTC 2013
Glen Barber <gjb at FreeBSD.org> wrote
in <20131202160333.GI1839 at glenbarber.us>:
gj> > - In the current release.sh, variables unintentionally set in the
gj> > builder's environment still pollutes commands which run in
gj> > release.sh when the variables are not set in the script but
gj> > accepted by make or other utilities. Catching all of the variables
gj> > is quite difficult.
gj> >
gj>
gj> Do you have an example? If you are referring to a previous problem with
gj> 10.x builds, the actual problem was a race in the build toolchain, and
gj> not variable pollution. I was able to confirm this was the case there.
One of the surprising examples I experienced was that svn co
sometimes fails with LC_ALL=C. Subversion stores repo data in UTF-8,
so iconv conversion happens when LC_ALL is not UTF-8 compatible (and
it broke "svn co head/" a while ago). Besides, TARGET, TARGET_ARCH,
MAKEOBJDIR, MAKEOBJDIRPREFIX, and OBJDIR are also dangerous and
unprotected variables for make(1). An empty TARGET caused an
infinite loop in libc build, so I fixed it in Makefile yesterday.
All of them are examples of "unintentional" variables, so being
careful is enough to avoid them, though.
gj> > Anyway, I do not have a strong opinion if using FOO=A or : ${FOO:=A}.
gj> > I agree that the latter assumes all of the envvars must be under
gj> > control and it needs one more step than just invoking the script, and
gj> > a leaked variable can break the build. If you do not like it, I will
gj> > change them with FOO=A.
gj> >
gj>
gj> Yes, please.
Will do. I will not merge the changes before 10.0R is out in any
case.
-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-user/attachments/20131203/4ca22732/attachment.sig>
More information about the svn-src-user
mailing list