From owner-freebsd-current@FreeBSD.ORG Mon Apr 28 16:10:01 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 0829BD03 for ; Mon, 28 Apr 2014 16:10:01 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (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 C321610C6 for ; Mon, 28 Apr 2014 16:10:00 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id rp18so1458051iec.32 for ; Mon, 28 Apr 2014 09:09:54 -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=Rt+HCHAxJFNG9tgLWTpnn9xw7GMVqeeIc7gM3T1D3Sg=; b=gEgGgC2zbyjeu1wAP8pfLQ8kXfZP1gsDcfPJoWKRlvmTgRH8vruvcBbHmlEpEneLX+ R7d4V/qNXBmj1+6gMPKXKJsRZ24FlYR16lmgWi6e6XvYc3mZaAU9alEw8iW2D/2EejZI wPTvQm4D1Fzk2W5OmLVclgzWAzw9rvA6apexSUCJ8oaTGyI/EmCT93rNxmOyp2OoBiGz V11ZA5Fwl+b5U4x9vuOgEaviAdQyOV+G6fmxfAYaw4fOUGS1Ca+fbbRi7imqGCyghIWX dPWWDWIxQClt+6tY4Zv4G2eaMwerOpnViyXjHZvIybWIOv+o+m41kgfdqIqIA4I/JRL9 toNA== X-Gm-Message-State: ALoCoQl7YzCBTU/rwTYH2WHgTCSHv6Q8rueJn9DGpd9Vu5p+s1wZV1hESvA8o+Ro9RWMFbrBfc6H X-Received: by 10.50.102.103 with SMTP id fn7mr24941682igb.22.1398701067213; Mon, 28 Apr 2014 09:04:27 -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 p9sm26790680igj.16.2014.04.28.09.04.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Apr 2014 09:04:26 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 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: Date: Mon, 28 Apr 2014 10:04:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Kevin Oberman X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Current , Ian Lepore 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 16:10:01 -0000 On Apr 28, 2014, at 9:52 AM, Kevin Oberman wrote: > 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. 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. > 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. 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? > 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. 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. > The only exception I might see is the building of a kernel module = which > might need to know how the system was made and that would be in the > specific port's Makefile, not a system wide file. I=92m not sure I understand here. If a kernel module uses the kernel = module build stuff, it should be affected by the src.conf files unless you = specifically request otherwise because you know what you are doing (e.g., building for = another system, cross building, etc). Warner=