From nobody@FreeBSD.org  Wed Aug  7 16:45:02 2013
Return-Path: <nobody@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 ESMTP id D3C54C93
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  7 Aug 2013 16:45:02 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.freebsd.org (Postfix) with ESMTPS id C09F227DE
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  7 Aug 2013 16:45:02 +0000 (UTC)
Received: from oldred.freebsd.org ([127.0.1.6])
	by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r77Gj284026704
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 7 Aug 2013 16:45:02 GMT
	(envelope-from nobody@oldred.freebsd.org)
Received: (from nobody@localhost)
	by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r77Gj2Du026703;
	Wed, 7 Aug 2013 16:45:02 GMT
	(envelope-from nobody)
Message-Id: <201308071645.r77Gj2Du026703@oldred.freebsd.org>
Date: Wed, 7 Aug 2013 16:45:02 GMT
From: Garrett Cooper <yaneurabeya@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         181116
>Category:       conf
>Synopsis:       CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 07 16:50:00 UTC 2013
>Closed-Date:    
>Last-Modified:  Wed Aug  7 21:50:01 UTC 2013
>Originator:     Garrett Cooper
>Release:        10-CURRENT
>Organization:
EMC Isilon
>Environment:
FreeBSD fuji-current.local 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r+b278358-dirty: Sun Jun  9 16:05:39 PDT 2013     root@fuji-current.local:/usr/obj/usr/src/sys/FUJI-NOCOMPAT  i386
>Description:
/etc/src.conf has WITHOUT_BMAKE specified, but the build isn't honoring it:

root@fuji-current:/usr/src # make -VWANT_MAKE
bmake
root@fuji-current:/usr/src # grep BMAKE /etc/src.conf 
WITHOUT_BMAKE=
root@fuji-current:/usr/src # make -VWANT_MAKE -DWITHOUT_BMAKE
fmake

commit 234508f586dc6e64c1ecee945d0fee8ce138ee66
Merge: 58b160f 3a26c75
Author: Garrett Cooper <yanegomi@gmail.com>
Date:   Wed Aug 7 09:15:20 2013 -0700

    Merge branch 'master' of github.com:yaneurabeya/freebsd

This logic needs to be fixed so it honors /etc/src.conf properly.
>How-To-Repeat:
cd /usr/src
echo WITHOUT_BMAKE= >> /etc/src.conf
[ "$(make -VWANT_MAKE)" != bmake ]
>Fix:


>Release-Note:
>Audit-Trail:

From: Garrett Cooper <yaneurabeya@gmail.com>
To: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@FreeBSD.org>,
 "freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>
Cc: "Simon J. Gerraty" <sjg@juniper.net>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 10:39:59 -0700

 FYI
 
 On Aug 7, 2013, at 4:50 PM, FreeBSD-gnats-submit@FreeBSD.org wrote:
 
 > Thank you very much for your problem report.
 > It has the internal identification `conf/181116'.
 > The individual assigned to look at your
 > report is: freebsd-bugs.=20
 >=20
 > You can access the state of your problem report at any time
 > via this link:
 >=20
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D181116
 >=20
 >> Category:       conf
 >> Responsible:    freebsd-bugs
 >> Synopsis:       CURRENT build always uses bmake, even though WITHOUT_BMAK=
 E is specified
 >> Arrival-Date:   Wed Aug 07 16:50:00 UTC 2013

From: "Simon J. Gerraty" <sjg@juniper.net>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@FreeBSD.org>,
	"freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 10:51:33 -0700

 src/Makefile does not read bsd.own.mk so does not see src.conf
 it does however see make.conf
 
 More importantly, is this a "test" or is there a percieved need to
 continue building with fmake?  If so why?
 
 I was aiming to get rid of WITH[OUT]_BMAKE soon - in time for 10.0
 
 

From: "Simon J. Gerraty" <sjg@juniper.net>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@FreeBSD.org>,
	"freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 10:54:51 -0700

 Also the synopsis is somewhat missleading.
 
 It only doesn't work when WITHOUT_BMAKE is specified in src.conf which 
 src/Makefile does not honor - so would apply to any WITH[OUT]_ knob.
 
 But the larger question is why you are wanting to use fmake 
 
 Thanks
 --sjg
 

From: Garrett Cooper <yaneurabeya@gmail.com>
To: "Simon J. Gerraty" <sjg@juniper.net>
Cc: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@FreeBSD.org>,
 "freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 11:24:15 -0700

 On Aug 7, 2013, at 10:51 AM, "Simon J. Gerraty" <sjg@juniper.net> wrote:
 
 >=20
 > src/Makefile does not read bsd.own.mk so does not see src.conf
 > it does however see make.conf
 
 Ah, but src.conf controls WITH* (and the option is documented in the manage,=
  along with all the others). You accidentally broke POLA :(.
 
 > More importantly, is this a "test" or is there a percieved need to
 > continue building with fmake?  If so why?
 
 I gave up waiting for bmake and all the associated infrastructure to be back=
 ported to stable/9 (and I know there's a snowball's chance in hades that it'=
 ll be backported to stable/8), so I figured out how to make the test infrast=
 ructure work independent of bmake.
 
 > I was aiming to get rid of WITH[OUT]_BMAKE soon - in time for 10.0
 
 This is a really bad idea. The fact that bmake causes conf/179111 without a m=
 itigation strategy is reason alone to leave this knob in because I don't tru=
 st all makefiles that exist outside of FreeBSD to work sanely without set -e=
 . Heck, a lot of the Makefile snippets in FreeBSD don't behave sanely withou=
 t set -e, as noted in the bug (and those are just a handful).
 
 Management at $work would agree that it makes no sense wasting engineering h=
 ours chasing down build faults.=

From: "Simon J. Gerraty" <sjg@juniper.net>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@FreeBSD.org>,
	"freebsd-bugs@FreeBSD.org" <freebsd-bugs@FreeBSD.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 13:32:17 -0700

 On Wed, 7 Aug 2013 11:24:15 -0700, Garrett Cooper writes:
 >Ah, but src.conf controls WITH* (and the option is documented in the manage,=
 > along with all the others). You accidentally broke POLA :(.
 
 The real issue is that the option handling needs an overhaul.
 
 The processing of options should be extracted from bsd.own.mk to its own
 mk file which is always safe to include - bsd.own.mk is not.
 Then makefiles like src/Makefile could include it with the list of
 options it cares about - and bsd.own.mk could do the same.
 
 >> More importantly, is this a "test" or is there a percieved need to
 >> continue building with fmake?  If so why?
 >
 >I gave up waiting for bmake and all the associated infrastructure to be back=
 >ported to stable/9 (and I know there's a snowball's chance in hades that it'=
 >ll be backported to stable/8), so I figured out how to make the test infrast=
 >ructure work independent of bmake.
 
 Why should that force you to use fmake for head?
 
 >> I was aiming to get rid of WITH[OUT]_BMAKE soon - in time for 10.0
 >
 >This is a really bad idea. The fact that bmake causes conf/179111 without a m=
 >itigation strategy is reason alone to leave this knob in because I don't tru=
 >st all makefiles that exist outside of FreeBSD to work sanely without set -e=
 >. Heck, a lot of the Makefile snippets in FreeBSD don't behave sanely withou=
 >t set -e, as noted in the bug (and those are just a handful).
 
 You have the option of using .SHELL:  to configure shell description that will 
 set -e, though that will just perpetuate bad habbits.
 You said in 179111 that PR you have a patch?
 

From: Garrett Cooper <yaneurabeya@gmail.com>
To: "Simon J. Gerraty" <sjg@juniper.net>
Cc: "FreeBSD-gnats-submit@FreeBSD.org" <FreeBSD-gnats-submit@freebsd.org>, 
	"freebsd-bugs@FreeBSD.org" <freebsd-bugs@freebsd.org>
Subject: Re: conf/181116: CURRENT build always uses bmake, even though
 WITHOUT_BMAKE is specified
Date: Wed, 7 Aug 2013 14:40:25 -0700

 On Wed, Aug 7, 2013 at 1:32 PM, Simon J. Gerraty <sjg@juniper.net> wrote:
 >
 > On Wed, 7 Aug 2013 11:24:15 -0700, Garrett Cooper writes:
 >>Ah, but src.conf controls WITH* (and the option is documented in the manage,=
 >> along with all the others). You accidentally broke POLA :(.
 >
 > The real issue is that the option handling needs an overhaul.
 
 I'm not arguing that it could be done better, but the problem is that
 bsd.own.mk is very tied to the source tree and is conditional on a
 number of factors (architecture, knobs tuned, etc).
 
 > The processing of options should be extracted from bsd.own.mk to its own
 > mk file which is always safe to include - bsd.own.mk is not.
 > Then makefiles like src/Makefile could include it with the list of
 > options it cares about - and bsd.own.mk could do the same.
 
 I don't think it's as possible as you would hope, but I wish you the
 best of luck.
 
 >>> More importantly, is this a "test" or is there a percieved need to
 >>> continue building with fmake?  If so why?
 >>
 >>I gave up waiting for bmake and all the associated infrastructure to be back=
 >>ported to stable/9 (and I know there's a snowball's chance in hades that it'=
 >>ll be backported to stable/8), so I figured out how to make the test infrast=
 >>ructure work independent of bmake.
 >
 > Why should that force you to use fmake for head?
 
 I'm verifying that my changes will continue to work with head because
 our port to CURRENT effort at $work is now being done in an iterative
 manner.
 
 We also aren't going to switch to bmake in 10. We're 4 months behind
 CURRENT right now (I know it's changed a lot in the last couple
 months), but $product images produced in fmake work (they actually
 boot) whereas images produced with bmake don't (files a missing,
 stuff's miscompiled, etc). And don't even get me started on our
 ancient Frankenstenian ports tree.
 
 Similarly, we're not going to switch to the new shiny toolchain bits
 (clang, libc++, etc), because of time and delivery dates. Too much
 stuff is going on in 10 that we need to stage things better for later
 releases.
 
 >>> I was aiming to get rid of WITH[OUT]_BMAKE soon - in time for 10.0
 >>
 >>This is a really bad idea. The fact that bmake causes conf/179111 without a m=
 >>itigation strategy is reason alone to leave this knob in because I don't tru=
 >>st all makefiles that exist outside of FreeBSD to work sanely without set -e=
 >>. Heck, a lot of the Makefile snippets in FreeBSD don't behave sanely withou=
 >>t set -e, as noted in the bug (and those are just a handful).
 >
 > You have the option of using .SHELL:  to configure shell description that will
 > set -e, though that will just perpetuate bad habbits.
 
 What bad habits do you think it's perpetuating?
 
 > You said in 179111 that PR you have a patch?
 
 There are a couple, yes.
>Unformatted:
