From owner-freebsd-current@FreeBSD.ORG Mon Apr 28 17:50:08 2014 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44A0649E for ; Mon, 28 Apr 2014 17:50:08 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 091301AC8 for ; Mon, 28 Apr 2014 17:50:07 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id h3so5081452igd.2 for ; Mon, 28 Apr 2014 10:50:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=78xqyII2bkvq40lARDcUAxymc9bfzcoWFxbXEmQNic8=; b=IERpVlOGnbOvKi82eWn0j09cVl+1dnfkvC7bQdY5JNKiCCivQYedDtREb9+Nos0B5o 0BzJa+4l3crfieRpmuqn5HEgKaxxH1CmDhy5JzZeHIi+xJdBTuf56uf/VjsldWiOqiGl t3Al0vk6EdHrsYVoXgFGY+K6RaPEF7+SKklrswT9m53u4YCQ7504V2Swbdj8aMpGuuCn 9FZBXrXUXLmQ38mVhlrvKfE0gZd/emW8HUlxu/cxATM+WbWeI4ptaKUCfIy5Rp9twgas T8O4myAYfrsAMaYMKcAvVII92rceUdwo8cbkNDBxjKwkB9RfcPY9kJpDQdVskUKOiGbN wfBg== X-Gm-Message-State: ALoCoQnOzCOwvVq675NdWjaBOIUMU1QS3qGJIVD/mZUEy2pIe45U0jEGLyxw14ndr2FzakV9yqqx X-Received: by 10.50.141.198 with SMTP id rq6mr25426921igb.38.1398707407066; Mon, 28 Apr 2014 10:50:07 -0700 (PDT) Received: from [10.0.0.119] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id m1sm27580960igx.13.2014.04.28.10.50.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 10:50:06 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1253 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: options for forcing use of GCC From: Warner Losh In-Reply-To: <1398706710.61646.228.camel@revolution.hippie.lan> Date: Mon, 28 Apr 2014 11:50:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <1398706710.61646.228.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) 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:50:08 -0000 On Apr 28, 2014, at 11:38 AM, Ian Lepore wrote: > 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 = those >>>>>> 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 = only >>>> kernel and world. I've heard it said that the reality falls short = of >>>> that and src.conf settings inappropriately leak into ports builds. >>=20 >> That=92s 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=92t = happen. Perhaps >> it isn=92t 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 = things. >>> make.conf already provided for that. >>=20 >> If someone can show me a specific, verifiable leak, I=92ll look into = it. Vague >> rumors about possible issues that may have existed once upon a time >> aren=92t fruitful to chase. >>=20 >=20 > You've known me long enough to know that the "Vague rumors..." = sentence > doesn't describe the way I operate. Sorry that I misconstrued the sentiment you were expressing. My bad. > 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. >=20 > So I figured I'd do a quick look for ports makefiles that are = including > bsd.[lib|prog|subdir].mk : >=20 > revolution > find . -name Make* | xargs grep bsd.*mk | \ > grep -v bsd.port| grep -E "lib.mk|prog.mk|subdir.mk" | wc -l > 66 Ah, it is affecting the building of the actual ports, not the = bsd.ports.mk system. That=92s the kind of detail that=92s good to know. In the near future, = that won=92t happen, unless the port=92s controlling Makefile. > 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. It is sufficient for me to get the issue. I=92d mistakenly thought it = was affecting ports build orchestration, but it is affecting anything that causes = bsd.own.mk to be included using our make(1). Since I thought it was a reference to = the former I was quite confused. Now that I know it is to the latter, I=92m = no longer confused. > 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. I agree as well=85 Which is why I have been moving the options into their own file and separating them into different categories. In my tree I have a = src.opts.mk file now, which is easy enough to do from where we are in the tree. The trouble is untangling it so that we can set it free from the = bsd.*.mk files and have it only influence the /usr/src build without breaking = other currently useful features of the /usr/src build. My plan is to move = inclusion of src.conf into that file once I work those kinks out. Once that = happens, then only make.conf will affect the subordinate builds that opt to use = the bsd.*.mk. I=92ve been reluctant to commit this next step because to not = break things, I=92d have to install src.opts.mk, which could cause issues down = the road if I find a way to not install it=85 This should move us fully to = an opt-in design=85. Warner > [1] > = http://lists.freebsd.org/pipermail/freebsd-current/2013-February/039709.ht= ml >=20 > -- Ian