From owner-freebsd-bugs@FreeBSD.ORG Wed Aug 7 21:40:27 2013 Return-Path: Delivered-To: freebsd-bugs@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 1D488A62; Wed, 7 Aug 2013 21:40:27 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BE0772BD9; Wed, 7 Aug 2013 21:40:26 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id db10so2427070veb.28 for ; Wed, 07 Aug 2013 14:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hVMEXy6FI04hI4I7NDYdCkJ5vZjslIkFjdB9NZIxGDg=; b=K5S2Hv0QmyvW/+FH2NM3S8C1Kt4LXaCdpA4x7zMraJrhz3MOwoqf41fniikt1NiM1J LThYo3iZBvk0XXLjzHZvCbzwyD2QqTHcRVLdoiXUOx8QZIWyjjW6hFjWPp4Gg7sH6MR8 OysRk/EaS6d/gF9uDMXyP9mI8n8dZ7HOvTi8DI4wb5RJeDFzsApZEE+Wl6bWxzYKid6r RpSRwZwkEaCF3CSQCuigl9zyFsZja+y1wYSFHIQ85tH7syORy886MsP4lR35CjuQHFaY fwDrV8VhnVXRLG76Xd3/dIH+jotYSf1IFjed2KJxIT87eNfeHnemMRUwec0nF149lPLP iZWw== MIME-Version: 1.0 X-Received: by 10.58.128.71 with SMTP id nm7mr1570298veb.51.1375911625918; Wed, 07 Aug 2013 14:40:25 -0700 (PDT) Received: by 10.220.146.145 with HTTP; Wed, 7 Aug 2013 14:40:25 -0700 (PDT) In-Reply-To: <20130807203217.A57FB58097@chaos.jnpr.net> References: <201308071650.r77Go0ql017340@freefall.freebsd.org> <20130807175133.A099D58097@chaos.jnpr.net> <20130807203217.A57FB58097@chaos.jnpr.net> Date: Wed, 7 Aug 2013 14:40:25 -0700 Message-ID: Subject: Re: conf/181116: CURRENT build always uses bmake, even though WITHOUT_BMAKE is specified From: Garrett Cooper To: "Simon J. Gerraty" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-bugs@FreeBSD.org" , "FreeBSD-gnats-submit@FreeBSD.org" X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 21:40:27 -0000 On Wed, Aug 7, 2013 at 1:32 PM, Simon J. Gerraty 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.