From owner-freebsd-arch@FreeBSD.ORG Wed Apr 2 21:23: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 82BCC68E; Wed, 2 Apr 2014 21:23:40 +0000 (UTC) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) (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 2FA7BDF2; Wed, 2 Apr 2014 21:23:40 +0000 (UTC) Received: from mail6-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Wed, 2 Apr 2014 21:23:33 +0000 Received: from mail6-va3 (localhost [127.0.0.1]) by mail6-va3-R.bigfish.com (Postfix) with ESMTP id 5533B46057E; Wed, 2 Apr 2014 21:23:33 +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: 4 X-BigFish: VPS4(zz1432Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208ch1082kzz1de097h74efjz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail6-va3: 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 mail6-va3 (localhost.localdomain [127.0.0.1]) by mail6-va3 (MessageSwitch) id 1396473810418663_19572; Wed, 2 Apr 2014 21:23:30 +0000 (UTC) Received: from VA3EHSMHS041.bigfish.com (unknown [10.7.14.249]) by mail6-va3.bigfish.com (Postfix) with ESMTP id 5796820074; Wed, 2 Apr 2014 21:23:30 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by VA3EHSMHS041.bigfish.com (10.7.99.51) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 21:23:30 +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; Wed, 2 Apr 2014 14:23:29 -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 s32LNSV53393; Wed, 2 Apr 2014 14:23: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 7CE8958097; Wed, 2 Apr 2014 14:23:28 -0700 (PDT) To: Warner Losh Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: <2349B38E-F6F2-4911-92F2-3D62FCBD73DA@bsdimp.com> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@chaos.jnpr.net> <20140401195249.8752258097@chaos.jnpr.net> <2349B38E-F6F2-4911-92F2-3D62FCBD73DA@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 02 Apr 2014 11:59:10 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 2 Apr 2014 14:23:28 -0700 Message-ID: <20140402212328.7CE8958097@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: Baptiste Daroussin , freebsd-arch@freebsd.org 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: Wed, 02 Apr 2014 21:23:40 -0000 >> which are needed during sys.mk can be influenced by user's -DWITH[OUT_* > >OK. A bit of a contrived example, but I suppose if I understood the meta mo= >de Actually not contrived at all - we have that internally. Ie. we have a local.sys.mk to set all our cool stuff but we currently just test for .ifdef WITH[OUT]*, hence this thread. >a bit better I might think differently :) > >I=92m a bit hesitant, though, to have this affect sys.mk because that affec= >ts all users >of make, not just /usr/src. That's why I'd put such things in local.sys.mk or some other makefile that affects /usr/src but isn't install into /usr/share/mk/ >In some cases, you can declare a winner. In other cases that might be harder >to do. With almost all options defaulting to YES, having WITHOUT win makes >good sense. When there=92s more of a mix, I=92m less sure. Agreed, that's why I took the easy way out by allowing the winner to be configured if the need should arise ;-) >> Traditionally done in bsd.obj.mk - but that requires a separate >> invocation of make. > >Right, but can=92t that be done automatically w/o that extra invocation? Yes provided you do it early enough (ie during sys.mk) eg. before you've evaluated things that affect .PATH >Back to the NO_CTF stuff I talked about above: I totally get this. If you l= >There=92s one place in the tree that wants to turn off CTF. This is mostly = >fixed by >just setting MK_CTF=3Dno in that makefile after we include bsd.own.mk. I say Wouldn't it be simpler to set MK_CTF=no *before* including bsd.own.mk ? >mostly fixed because we wind up with a NULL command where we really want >a @: command, though the former I believe is harmless but verbose. Except >one could unset WITH_CTF (which doesn=92t completely work, it still shows >up as defined) and set WITHOUT_CTF before bsd.own.mk and it would work, >modulo this bug. > >This can really only be fixed by making bsd.own.mk look more like > ># section 1 -same >.include ># section 3 - same > >with bsd.options.mk looking a lot like section 2 of bsd.own.mk. Also, we= >=92d have Yes, that's essentially what I was proposing. By extracting the mechanism to its own file, it can be re-used. >This sounds a lot like what you=92re trying to describe, though placement of >bsd.options.mk may be different than I described. The only reason we >need it where I suggested it is compatibility with the past. Though we may Yes I assumed it would be included as above - to avoid changing behavior unnecessarily. Note: tweaking the semantics and making it re-usable are somewhat orthogonal. >be able to get away with it in sys.mk, I=92m hesitant to place it in there = >because >that=92s global to everything, including ports, etc. Plus, I think it is to= Calling it bsd.options.mk is a conflict with ports. Though including it as "bsd.options.mk" both in bsd.own.mk and in the relevant ports makefile, should probably mitigate that. >o early, due to meta MK_ variables, that I talk about below. >> .if defined(MK_${var}) >> .if ${.MAKE.LEVEL} =3D=3D 0 >> .error MK_${var} can't be set by a user. >> .endif >> = > >> would seem to negate that. Why can a makefile at level 0 not set MK_*? > >Well, the notion now is that if you want to test MK_* variables, you need to >include bsd.own.mk first. The notion I was going for with the above is that= Setting MK_* before bsd.own.mk vs after has semantic differences but that shouldn't preclude doing either. Eg. the knob names below describe the semantics # these remove choice from user MK_CANNOT= no MK_MUST= yes .include # these respect user choices MK_LIKE?= yes MK_DISLIKE?= no >But there=92s a problem even if we take the approach above. Section 2 in bs= >d.own.mk >is actually two separate sections. One that sets the MK_* variables based on >WITH_ or WITHOUT_ and then a second section that cascades the MK_ variables >to other MK_ variables (like MK_CRYPT=3D=3Dno turning of OpenSSL, Kerberos,= > etc). If >you wanted to set one of those variables in your Makefile, you=92d have a c= >hicken >and egg problem. If you set it before bsd.options.mk, then you=92d get the = >cascade effects >but hit the warning. If you set it after, you dodge the warning, but don=92= >t get the cascade. Per above setting MK_* before including bsd.own.mk is just supressing user input, probably not something to do a lot, but handy at times - eg. allows doing away with NO_* If that has cascading effects, we assume they are intended. Currently, what warning do you hit btw? I only see .errors if MK_* is pre-defined or WITH[OUT]* both defined. >This problem suggests, perhaps, that the test be deleted. > >> The outstanding question is dealing with conflict when both WITH_FOO and >> WITHOUT_FOO are defined. > >True. That=92s a tougher problem than you might think on first blush, as we= >=92ve >been talking about. For now, I=92d suggest WITHOUT wins, and we see how far Agreed. I cannot currently think of a case where that wouldn't be right, but as I mentioned wrt my options.mk it is easy to allow configurability should the need arise. Thanks --sjg