From owner-freebsd-testing@FreeBSD.ORG Thu Jan 23 22:40:04 2014 Return-Path: Delivered-To: freebsd-testing@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 1C783B66; Thu, 23 Jan 2014 22:40:04 +0000 (UTC) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9232148D; Thu, 23 Jan 2014 22:40:03 +0000 (UTC) Received: from mail204-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Thu, 23 Jan 2014 21:54:41 +0000 Received: from mail204-co1 (localhost [127.0.0.1]) by mail204-co1-R.bigfish.com (Postfix) with ESMTP id 71C801C0089; Thu, 23 Jan 2014 21:54:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.11; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kz8dhz1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h1155h) Received-SPF: softfail (mail204-co1: transitioning domain of juniper.net does not designate 66.129.239.11 as permitted sender) client-ip=66.129.239.11; envelope-from=sjg@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail204-co1 (localhost.localdomain [127.0.0.1]) by mail204-co1 (MessageSwitch) id 139051407923561_20197; Thu, 23 Jan 2014 21:54:39 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.232]) by mail204-co1.bigfish.com (Postfix) with ESMTP id 012E1A80047; Thu, 23 Jan 2014 21:54:39 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 23 Jan 2014 21:54:38 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 23 Jan 2014 13:54:37 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id s0NLsWL74407; Thu, 23 Jan 2014 13:54:32 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 4B7B15807E; Thu, 23 Jan 2014 13:54:30 -0800 (PST) To: Garrett Cooper Subject: Re: Makefile.inc1.patch In-Reply-To: References: <4A3E3984-73D3-4441-97A7-D58679EFF978@gmail.com> <9775878D-91AB-4BE4-ADFA-32D8DB582AA6@gmail.com> <20140123210308.0E1D65807E@chaos.jnpr.net> Comments: In-reply-to: Garrett Cooper message dated "Thu, 23 Jan 2014 13:30:12 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 23 Jan 2014 13:54:30 -0800 Message-ID: <20140123215430.4B7B15807E@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "freebsd-testing@freebsd.org" , brooks@freebsd.org, sjg@juniper.net X-BeenThere: freebsd-testing@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Testing on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 22:40:04 -0000 On Thu, 23 Jan 2014 13:30:12 -0800, Garrett Cooper writes: >> Not crazy about frobbing ${MAKE} > >Neither am I, but .export is a bmake only feature. I=92m still using = >fmake :(. Not necessarily a good excuse ;-) >> The semantics in bsd.own.mk are quite broken and result in a lot of = >complex >> dancing to keep things working. > >In this case though, this is complex dancing due to how the different = >stages stack upon one another in the build process and the fact that = >meta make isn=92t here (yet), so things have to be built in the right = >order. This method is one that I=92ve been using for quite some time = >without any side effects on multiple machines... Actually a simple tweak to the bsd.own.mk semantics would alleviate of lot of the pain. Throwing errors if MK_* is already set, or if both WITH_* and WITHOUT_* are set makes the usage very messy indeed. For options.mk I allow MK_* to already be set and WITHOUT_* to take precedence over WITH_*. I also allow makefiles to have their own lists of options - separate the policy from the mechanism. I guess you could even allow a per-knob setting as to which takes precedence. By simply allowing WITHOUT_* to overrule WITH_*, the Makefile.inc1 usage would be greatly simplified.