Date: Sun, 7 Dec 2014 18:39:05 -0800 From: Garrett Cooper <yaneurabeya@gmail.com> To: Ian Lepore <ian@FreeBSD.org> Cc: FreeBSD CURRENT <freebsd-current@freebsd.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: Build failed in Jenkins: Build-UFS-image #599 Message-ID: <73D1710E-6242-44DB-9BAA-84F20B341799@gmail.com> In-Reply-To: <1417885034.1064.83.camel@revolution.hippie.lan> References: <1052304530.8.1417827164793.JavaMail.jenkins@jenkins-9.freebsd.org> <D290A7DA-0AED-4810-A1B1-470E35542292@gmail.com> <7A7677F9-AD1B-436C-9A49-054F7CD6BBC4@FreeBSD.org> <1417885034.1064.83.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <ian@FreeBSD.org> 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 <yaneurabeya@gmail.com> = wrote: >>> On Dec 5, 2014, at 16:52, jenkins-admin@freebsd.org wrote: >>>=20 >>>> See <https://jenkins.freebsd.org/job/Build-UFS-image/599/>; >>>=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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73D1710E-6242-44DB-9BAA-84F20B341799>