From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 05:13:40 2014 Return-Path: Delivered-To: freebsd-arch@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 0743D1D33 for ; Tue, 1 Apr 2014 05:13:40 +0000 (UTC) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B47EABB1 for ; Tue, 1 Apr 2014 05:13:39 +0000 (UTC) Received: from mail184-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Tue, 1 Apr 2014 05:13:32 +0000 Received: from mail184-ch1 (localhost [127.0.0.1]) by mail184-ch1-R.bigfish.com (Postfix) with ESMTP id 492A12601FD for ; Tue, 1 Apr 2014 05:13:32 +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: 3 X-BigFish: VPS3(zzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kzz1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1dc1h1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh1155h) Received-SPF: softfail (mail184-ch1: 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 mail184-ch1 (localhost.localdomain [127.0.0.1]) by mail184-ch1 (MessageSwitch) id 1396329210401438_927; Tue, 1 Apr 2014 05:13:30 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail184-ch1.bigfish.com (Postfix) with ESMTP id 5CD0EC004F for ; Tue, 1 Apr 2014 05:13:30 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 1 Apr 2014 05:13:29 +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; Mon, 31 Mar 2014 22:13:28 -0700 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 s315DSV06440; Mon, 31 Mar 2014 22:13:28 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id F20F958097; Mon, 31 Mar 2014 22:13:27 -0700 (PDT) To: Subject: make WITH[OUT]_* more useful? X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Mon, 31 Mar 2014 22:13:27 -0700 From: Simon Gerraty Message-ID: <20140401051327.F20F958097@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: sjg@juniper.net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 05:13:40 -0000 I really like the idea of WITH[OUT]_* knobs translating to MK_* knobs, but I find the current implementation much less useful than I think it could be. Not the least of its problems is being implemented in bsd.own.mk which ties policy and mechanism together. It is not always (rarely) safe to include the in-tree bsd.own.mk which means that in many cases you cannot rely on MK_* at all, but have to re-implement the WITH_* vs WITHOUT_* logic repeatedly. It is also generally bad to include bsd.own.mk from sys.mk, which means any knobs you need early must re-implement the WITH_* vs WITHOUT_* logic repeatedly. contrib/bmake/mk/options.mk is an example of a more generic implementation with (I think) some advantages. The key semantic changes are (DOMINANT_* is from a newer version than in contrib): # NO_* takes precedence # If both WITH_* and WITHOUT_* are defined, WITHOUT_ wins unless # DOMINANT_* is set to "yes" # Otherwise WITH_* and WITHOUT_* override the default. and MK_* can be pre-set without causing an error. The key advantage is that the mechanism is separate from the policy. You can thus have knobs that get set much earlier (eg during sys.mk) and other knobs that get set later. Ie. both sys.mk and bsd.own.mk can include options.mk to process options that they care about, allowing MK_* to be used more consistently - you could use different prefix to avoid overlap, but that's probably not necessary. You can in fact have per-makefile option lists if you want (see contrib/bmake/Makefile) Thoughts?