From owner-freebsd-current@FreeBSD.ORG Mon Apr 28 17:38:35 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3A35F60 for ; Mon, 28 Apr 2014 17:38:35 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6F5AA19BD for ; Mon, 28 Apr 2014 17:38:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WepVh-000Jex-OK; Mon, 28 Apr 2014 17:38:33 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3SHcVUn015220; Mon, 28 Apr 2014 11:38:31 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18g6BK1MfHb74pAy/TDH2Ne Subject: Re: options for forcing use of GCC From: Ian Lepore To: Warner Losh In-Reply-To: <7E11EE0A-6BA0-4508-80ED-641876004540@bsdimp.com> References: <535D1350.4000106@freebsd.org> <1398616234.61646.155.camel@revolution.hippie.lan> <535DFB11.4020904@freebsd.org> <1398686749.61646.203.camel@revolution.hippie.lan> <535E5FA0.9050703@freebsd.org> <1398695014.61646.212.camel@revolution.hippie.lan> <7E11EE0A-6BA0-4508-80ED-641876004540@bsdimp.com> Content-Type: text/plain; charset="iso-8859-7" Date: Mon, 28 Apr 2014 11:38:30 -0600 Message-ID: <1398706710.61646.228.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id s3SHcVUn015220 Cc: Kevin Oberman , FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 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, 28 Apr 2014 17:38:35 -0000 On Mon, 2014-04-28 at 10:04 -0600, Warner Losh wrote: > On Apr 28, 2014, at 9:52 AM, Kevin Oberman wrote: >=20 > > On Mon, Apr 28, 2014 at 7:23 AM, Ian Lepore wrote: > >=20 > >> On Mon, 2014-04-28 at 22:03 +0800, Julian Elischer wrote: > >>> On 4/28/14, 8:05 PM, Ian Lepore wrote: > >>>> On Mon, 2014-04-28 at 14:54 +0800, Julian Elischer wrote: > >>>>> On 4/28/14, 12:30 AM, Ian Lepore wrote: > >>>>>> WITH_GCC=3Dyes \ > >>>>>> WITH_GNUCXX=3Dyes \ > >>>>>> WITHOUT_CLANG=3Dyes \ > >>>>>> WITHOUT_CLANG_IS_CC=3Dyes \ > >>>>> forgot to ask.. is this in /etc/make.conf? > >>>>> or elsewhere? > >>>> Actually in our build system we build in a chroot, and we inject t= hose > >>>> args into the environment during the builds so that we can have > >>>> different options for building world versus cross-world within the > >>>> chroot, but I think the more-normal place would be make.conf. > >>>=20 > >>> we also use a combination of environment and make.conf in a chroot. > >>> though people sometimes talk about a src.conf (or is that src.mk?) = but > >>> I haven't found that one yet. > >>>>=20 > >>>> -- Ian > >>>>=20 > >>>>=20 > >>>>=20 > >>=20 > >> In theory, /etc/make.conf affects all builds you do -- world, kernel= , > >> ports, your own apps, everything -- whereas /etc/src.conf affects on= ly > >> kernel and world. I've heard it said that the reality falls short o= f > >> that and src.conf settings inappropriately leak into ports builds. >=20 > That=A2s bogus. Port builds define _WITHOUT_SRCCONF which precludes not > only including /etc/src.conf, but also disables the while WITH/WITHOUT_= FOO > mechanism from converting those options into MK_FOO options. >=20 > > I have also heard this, but a grep of ports/Mk finds no matches to > > src\.conf, so this appears to not be the case. >=20 > Ports specifically goes out of its way to make sure this doesn=A2t happ= en. Perhaps > it isn=A2t going out of its way far enough? >=20 > > It should not be as the whole purpose of src.conf was to have a make > > configuration that would be used to build the system, but not other t= hings. > > make.conf already provided for that. >=20 > If someone can show me a specific, verifiable leak, I=A2ll look into it= . Vague > rumors about possible issues that may have existed once upon a time > aren=A2t fruitful to chase. >=20 You've known me long enough to know that the "Vague rumors..." sentence doesn't describe the way I operate. I was vague on the fine details, but I remember an email thread where it was specifically shown that the contents of src.conf were affecting ports builds. I just tracked it down [1] and about midway through that thread it materialized that some ports' makefiles include bsd.prog.mk or bsd.lib.mk and that leads to the inappropriate inclusion of src.conf into a port build. So I figured I'd do a quick look for ports makefiles that are including bsd.[lib|prog|subdir].mk : revolution > find . -name Make* | xargs grep bsd.*mk | \ grep -v bsd.port| grep -E "lib.mk|prog.mk|subdir.mk" | wc -l 66 That's probably not a perfect search, but it looks like there are a few ports that may be perturbed by src.conf settings, plus as was revealed in that thread, if you use /usr/share/mk/bsd.*.mk for your own software (as we do at $work) then your own builds are also affected by src.conf. I quite agree with the sentiments expressed in that thread that the genesis of the problem is the opt-out nature of src.conf. If it had been designed as an opt-in feature with a handful of /usr/src makefiles opting in as-needed, maybe the situation would be cleaner today. Then again, maybe that leads to other problems -- it's always easy to say "the right thing to do would have been..." when you haven't fought your way through actually making your plan work. [1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039709.h= tml -- Ian