Date: Mon, 2 Dec 2013 12:20:52 -0500 From: Glen Barber <gjb@FreeBSD.org> To: Hiroki Sato <hrs@FreeBSD.org> Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release Message-ID: <20131202172052.GK1839@glenbarber.us> In-Reply-To: <20131203.021439.505942678651568262.hrs@allbsd.org> References: <20131202152054.GH1839@glenbarber.us> <20131203.005247.163975247035953783.hrs@allbsd.org> <20131202160333.GI1839@glenbarber.us> <20131203.021439.505942678651568262.hrs@allbsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Tue, Dec 03, 2013 at 02:14:39AM +0900, Hiroki Sato wrote:
> 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.
I saw your fix for empty TARGET. I ran into that problem quite some
time ago.
> 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.
>
Right, but I will still likely have to change build scripts (again) for
head/ snapshots...
Glen
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBCAAGBQJSnMF0AAoJELls3eqvi17Qn4AQAMgWiZbvQPZgdk6FZtglVKdD
Ti/ogRkY28oNOpHpCregIT6XkHwXA39iaqG6gQOSgaQUrrO9NWtQWr2hZlAglR3Q
3cZgrV++IBYc4enJlagaelIBvwfc088Zi21VWsv4gQYwXi7+p0IhPWr+7tCOkfEF
toX43HKoAAim0xMCezClAOXoWX0FVEoDobDHXP3TAODgcnC8pOjIlW8+fel/im9I
Io+8Nd54r+VfHi40FhnURtEO9AibYqjUMD6gUnHqM8X7WQ2aCGbLPT6V69Dh2TA4
mjVPRVQpIUc9wzvnethrkC6msm1d58B+sT5fDtDRt56XvDXVELD3dGffJlh7dUeb
cgUJHw9E8FszvVMxrd1TwPla+jTzl/wh6yb8xomS+o27Et6MY2w8OUTNIwJL8TNU
hulprcj3/3mU8NrMMfMNDVxyhRTPP1DH3Ed60ByKonrz0UIkfW4vX6PQ45/Zwh9i
6IFeiMo3ienJpaP8q5/EjqhAVR8ad+wjPLTRwpyzhNILMXY1J9TYd+knmHiie+fc
l+JPUwukR+qvHvBt880gwjC8+6GBK/L8xNLzi9nKKIKfieTwDUWhTmstv/W/Ttht
mpozAMq6ruyn1oMQGVshn7JmdItd2eHjD5bhHOvRx+vb0SIQZUrZzY8YJobiIqZH
21GS31VP6fwjZjQQ/B/Z
=5NeH
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131202172052.GK1839>