From owner-freebsd-current@FreeBSD.ORG Mon Dec 8 02:39:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BE8669D; Mon, 8 Dec 2014 02:39:08 +0000 (UTC) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0944B61F; Mon, 8 Dec 2014 02:39:08 +0000 (UTC) Received: by mail-ig0-f170.google.com with SMTP id r2so3531079igi.3 for ; Sun, 07 Dec 2014 18:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=7VC64HfOTlHIqADPpmdmDfUEDjY5+7ITZqTRxwE6YCQ=; b=BIbSTL8t2CIC8wFcOsGq9VgAWnEPyIpwCfJ4eNfyTsjCP4sNVLbIgVeXbsy4kUee2X VNtD58EFyIrWFTYp+070Ots5QWcw4Dirx3sclZ0cyhd9aatHZiWRL7DNkDLpe/UJ1pjZ yIlBzaTKBVw1KynrNES5VfUsArEkwD+Ualb8/9bBguk8yJdLAK+wsGBVRGNUZBJiZ4WR 6QDdH57tBOhVuJcGJyiOXSi+tXVkHI9P3zDDYNe3Yo/I4x9/ZimlDeN5UoOgbTRhBNZv NSg7Y1dj3aMypcF8kHOMY9JLKNUBelg3AEp6uO2Bu8um/0Hv60I+Rc377PtVL+mYGxEO N00g== X-Received: by 10.50.6.112 with SMTP id z16mr12695516igz.43.1418006347369; Sun, 07 Dec 2014 18:39:07 -0800 (PST) Received: from ?IPv6:2601:8:ab80:7d6:f855:3c8d:38d3:b94b? ([2601:8:ab80:7d6:f855:3c8d:38d3:b94b]) by mx.google.com with ESMTPSA id h77sm16043076ioe.35.2014.12.07.18.39.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Dec 2014 18:39:06 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_BA33F9E7-4769-4762-B31A-E262386A34D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Build failed in Jenkins: Build-UFS-image #599 From: Garrett Cooper In-Reply-To: <1417885034.1064.83.camel@revolution.hippie.lan> Date: Sun, 7 Dec 2014 18:39:05 -0800 Message-Id: <73D1710E-6242-44DB-9BAA-84F20B341799@gmail.com> References: <1052304530.8.1417827164793.JavaMail.jenkins@jenkins-9.freebsd.org> <7A7677F9-AD1B-436C-9A49-054F7CD6BBC4@FreeBSD.org> <1417885034.1064.83.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: FreeBSD CURRENT , Dimitry Andric X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 02:39:08 -0000 --Apple-Mail=_BA33F9E7-4769-4762-B31A-E262386A34D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 6, 2014, at 8:57, Ian Lepore wrote: > On Sat, 2014-12-06 at 16:01 +0100, Dimitry Andric wrote: >> [trimmed CC list to -current] >>=20 >> On 06 Dec 2014, at 04:59, Garrett Cooper = wrote: >>> On Dec 5, 2014, at 16:52, jenkins-admin@freebsd.org wrote: >>>=20 >>>> See >>>=20 >>> I=B4m not entirely sure why the "could not determine = COMPILER_TYPE" error popped up, but I have a couple of = questions/concerns related to the makefile snippet. >>> 1. Does it make sense to check CC when running make install? >>=20 >> Yes, of course it makes sense, if parts of the install depend on e.g. >> COMPILER_TYPE. In some cases, you will have to run ${CC} to = determine >> what it is, specifically if it is just "cc=94. Let me phrase it differently=85 do I need to run cc =97version if I=92m = just going to be running xinstall to install a bunch of binaries? Seems = like a serious waste of cycles to me. >>> 2. Why isn=B4t this value determined once in Makefile.inc1 (per = build phase), then passed down from there >>=20 >> Because you are supposed to be able to build stuff in a subdirectory, >> without invoking the full top-level Makefile infrastructure. The = actual >> infrastructure is in share/mk/bsd.*.mk, in fact. Let me rephrase this as well: why isn=92t the value cached once at the = top-level in a more intelligent way and passed down to bsd.compiler.mk? = It was always calculating ${CC} =97version on my branch for instance, = until I made this commit: = https://svnweb.freebsd.org/base/projects/building-blocks/share/mk/bsd.comp= iler.mk?r1=3D275556&r2=3D275558 (which I=92m going to merge back to head = right now because it=92s an unnecessary fork/popen/whatever=92s involved = to get the value of a throwaway variable). >>> (I=B4ve already considered the scenario where someone explicitly = sets CC in a non-toplevel Makefile, which is a problem, but an outlier = rather than the norm)? AFAICT, it gets recomputed for every recursive = make, which contributes to useless forking for something that honestly = doesn=B4t change all that often/at all. >>=20 >> This is indeed a pity, and if you know a better solution, let's hear = it, >> please. :-) =46rom my perspective, the only place it makes sense for CC to change it = during cross-tools based on Makefile.inc1. Before that it should be = value V.X, and before that it should be value Y.Z, where V.X and Y.Z = should be the same. So, the value should be calculated once in the = necessary sections, then passed down appropriately. >>> At EMC/Isilon at least, we set CC/CXX=3Dfalse when running make = distribute*/installkernel/installworld to catch logic errors with = rebuilding code. Should this be in FreeBSD? >>=20 >> Not sure what that is meant to achieve. If parts of the installation >> depend on the value of CC, why would you want to set it to false? = Just >> so it can error out at those points? >=20 > I suspect it's to prevent building during the install phase, because > doing so is astonishing. I was astonished the other day when it > happened. I would be much happier if it had just errored out. Yes. If dependencies changed, logically they shouldn=92t be recompiled = in the install phase. This could cause additional unexpected/weird = issues if say you updated libc, it recompiled the shared library, but = not the static library, and then stuff blew up later on. That=92s one = thing Isilon was trying to avoid because it reveals either bugs in the = build process, or bugs in the build environment, and it could result in = weirdness with produced binaries later on (especially if compat layers = change, linked libraries change, etc). Thanks! --Apple-Mail=_BA33F9E7-4769-4762-B31A-E262386A34D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUhQ9JAAoJEMZr5QU6S73eF1MH/3uctCBg9W4yoAJllfVwYrD5 6bKQmwmk/OZEPLFgQzyKumgO6jZvkJfUiZY5hEnxHGNgW5+rCDm3BuicSrUoRV6Q 1An12yfop05TqZggqqpCyrJ+Rw73j7eqVbxjPoe9C2KiFBA60RXW7CJ0MjX0cLnN UAYdVzSxO7CjsoqX5JhxbWDjdUJTzExklzQKxavQ/1sNMa6XSWRkhmzGDBjmPHnF V46I6h3XOUl68q4mbKiYOHDBvkc1FjPF7MqU493tur0Oof0qRxSzUcinXhASDf5E Wtd/FTgqTiatHthe8/TqvwyEjUX0H4rwa/zfpyM9XKRKMiykp1a8pl3UC3bR8Ow= =oita -----END PGP SIGNATURE----- --Apple-Mail=_BA33F9E7-4769-4762-B31A-E262386A34D0--