From owner-freebsd-arch@FreeBSD.ORG Thu Apr 10 03:46:57 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 8D980E46; Thu, 10 Apr 2014 03:46:57 +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 3FF8019A1; Thu, 10 Apr 2014 03:46:56 +0000 (UTC) Received: from mail44-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Thu, 10 Apr 2014 03:46:28 +0000 Received: from mail44-ch1 (localhost [127.0.0.1]) by mail44-ch1-R.bigfish.com (Postfix) with ESMTP id 277661204ED; Thu, 10 Apr 2014 03:46:28 +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(zz1432Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208ch1082kzz1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail44-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 mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1 (MessageSwitch) id 139710158669426_24333; Thu, 10 Apr 2014 03:46:26 +0000 (UTC) Received: from CH1EHSMHS039.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail44-ch1.bigfish.com (Postfix) with ESMTP id 0B2561801B4; Thu, 10 Apr 2014 03:46:26 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS039.bigfish.com (10.43.69.248) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 10 Apr 2014 03:46:25 +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, 9 Apr 2014 20:46:46 -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 s3A3kkV16230; Wed, 9 Apr 2014 20:46:46 -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 C058658097; Wed, 9 Apr 2014 20:46:45 -0700 (PDT) To: Warner Losh Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: <5D9BD168-D7E5-477E-AEA3-47B24445C89F@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> <20140402212328.7CE8958097@chaos.jnpr.net> <5D9BD168-D7E5-477E-AEA3-47B24445C89F@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Wed, 09 Apr 2014 15:13:32 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 9 Apr 2014 20:46:45 -0700 Message-ID: <20140410034645.C058658097@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, 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: Thu, 10 Apr 2014 03:46:57 -0000 >It sounds like we=92re in agreement on how to proceed, or very nearly = >so. I have some more >comments below, but I think the next order of business would be patches. = >Do you have some ready to roll? No, not yet - I figured getting some level of consensus fist was worthwhile. My cunning plan was simply to remove the mechanism from bsd.own.mk, and include the new file at approximately the original location. Thus not necessarily any functional change. The devil's in the details of course. I'm obviously biased, but I think contrib/bmake/mk/options.mk is close to what is desired - just the mechanism with no policy. >If so, then we should iterate on them. If not, I can = >find some time over >the coming days/weeks. I=92d like to have this done before BSDcan, but = >if not we can >chat then, assuming you are going. Sounds good, yes I'll be there. >> 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/ > >That=92s a bit of a departure over how we=92ve done things, but one that = >may make a good amount of sense. I've been distributing my *.mk files for a long time, and I prefer people leave them as is, so I make it easy for them to customize without hacking. Adding .-include "local.*.mk" allows for a lot of customization. When I wrote dirdeps.mk et al it was with the understanding that Juniper would make them publicly available, so used the same model. IIRC there was some discussion at dev summit or BSDCan last year about having src/ look for src.conf, make.conf etc inside the tree rather than /etc. I know in our internal builds we want to ensure that our src/ is self contained. >Where would the src build pick this up from if = >it isn=92t installed? src/share/mk should work fine. >> Wouldn't it be simpler to set MK_CTF=3Dno *before* including = >bsd.own.mk ? > >Well, kinda=85 Then the issue becomes, in what I think you are = >proposing, what happens >to the meta variables, or MK_foo that sets a lot of MK_bar. Assuming we = >move all of >them to their own file, we have two sections. One that sets MK_xxx = >variables based on >WITH/WITHOUT, and a second one that sets them based on other MK_xxx = >variables. >If I set MK_CTF=3Dno in my makefile, and it caused other MK_ flags to be = >set, then I=92d have >to include something to take another run at setting those = >meta-variables. Not necessarily. The stuff in bsd.own.mk like: .if ${MK_TOOLCHAIN} == "no" MK_BINUTILS:= no MK_CLANG:= no MK_GCC:= no MK_GDB:= no .endif doesn't need to change, and for more elaborate stuff, simply being able to include *options.mk more than once may help quite a bit. >> Yes, that's essentially what I was proposing. >> By extracting the mechanism to its own file, it can be re-used. > >Do you have patches? I think I like it... No, but could do so pretty quickly. I need to resync projects/bmake and start writing my material for BSDCan ;-) I could look doing this as part of that. The hardest bit is naming the new makefile ;-) bsd.options.mk would be an obvious choice - though that conflicts with ports usage. >> 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. > >I thought ports used a different mechanism and defined special magic so = >the >src tree mechanism was disabled. The ports makefile is much more elaborate but I believe achieves similar results. The name conflict could probably be worked around if bsd.options.mk is considered the best name choice. --sjg