From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 18:27:19 2014 Return-Path: Delivered-To: freebsd-arch@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 EE45EEAA; Thu, 17 Apr 2014 18:27:19 +0000 (UTC) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) (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 996BF122D; Thu, 17 Apr 2014 18:27:19 +0000 (UTC) Received: from mail73-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Apr 2014 18:11:24 +0000 Received: from mail73-va3 (localhost [127.0.0.1]) by mail73-va3-R.bigfish.com (Postfix) with ESMTP id 423731C033B; Thu, 17 Apr 2014 18:11:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.239.10; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208ch1082kzz1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail73-va3: transitioning domain of juniper.net does not designate 66.129.239.10 as permitted sender) client-ip=66.129.239.10; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail73-va3 (localhost.localdomain [127.0.0.1]) by mail73-va3 (MessageSwitch) id 1397758282699575_6011; Thu, 17 Apr 2014 18:11:22 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.237]) by mail73-va3.bigfish.com (Postfix) with ESMTP id A24654E0091; Thu, 17 Apr 2014 18:11:22 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.239.10) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Apr 2014 18:11:22 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 17 Apr 2014 11:12:04 -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 s3HIC2V33638; Thu, 17 Apr 2014 11:12:02 -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 0EFEA5809E; Thu, 17 Apr 2014 11:11:59 -0700 (PDT) To: Warner Losh Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@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> <20140410034645.C058658097@chaos.jnpr.net> <20140417063437.3BBF85809E@chaos.jnpr.net> <06CC1B46-2BF2-439C-8F97-16EA8DD7805C@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Thu, 17 Apr 2014 10:30:58 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 17 Apr 2014 11:11:59 -0700 Message-ID: <20140417181159.0EFEA5809E@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, 17 Apr 2014 18:27:20 -0000 On Thu, 17 Apr 2014 10:30:58 -0600, Warner Losh writes: >This was step one: separate out the options processing from the = >bsd.own.mk stuff. >Having a few lines that are generic would be nice to include. I=92d like = >to go ahead and >commit step 1, even if we refine things a bit later to keep the change = >sets manageable >and under control=85 Is that reasonable? It will help other areas and we = >don=92t need to >do much more than settle on filenames. :) Sure. Naming stuff is hard, and warrants early attention. On that front it occurred to me that (since it sets MK_*) bsd.mkopts.mk might be a good name for the pure mechanism makefile. So in the 3 level setup I mentioned you'd have: bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk If that sounds ok, I think we can proceed to next step. >> Sorry, which file are you talking about?=20 > >My bsd.srcopts.mk was what I was talking about here needing to be added = >to share/mk/Makefile. Ah right. This is why I think separating the mechanism is good. The mechanism should definitely be installed - because it is very handy (assuming some of the restrictions are removed). The /usr/src "policy" is another matter (possibly bikeshed material ;-) >> FWIW I think all bsd.*.mk should get installed. >> but I think it perfectly reasonable to declare that anything matching = >the >> pattern local.* or src.* doesn't get installed. >> Hopefully that shouldn't surprise anyone either. > >IF we can achieve that separation, then great. Yep. >> To restate that slightly differently, you can think of these things as = >a >> hierarchy: >>=20 >> bsd.* mechanism for building stuff (not just /usr/src) >> src.* stuff just for building /usr/src >> local.* local tweaks to all the above > >Yes, as long as the MK_FOO variables that are really src building stuff = >don=92t >infect the bsd.foo.mk files, this could work out. Exactly. MK_* which are meaningful to bsd.*.mk need an option list in bsd.*.mk - bsd.own.mk being perhaps a natural location? For MK_* which are only actioned in makefiles like *bin/Makefile they can be configured via a src.* file since they do not need to be installed. By providing guidance and "obvious" places to list the two classes of knobs we can limit the infection risk. >Would we do a wholesale change of bsd.foo.mk to src.foo.mk for all the = >Makefiles I'm not sure that would be necessary. Having to support lots of active branches makes me leery of gratuitous changes ;-) If we had sys.mk do .-include "src.sys.mk" .-include "local.sys.mk" that would be sufficient to enable all sorts of cool stuff. Similarly, bsd.init.mk doing .-include "src.init.mk" .-include "local.init.mk" would allow for customization of things to be done after Makefile has been read. The above would be sufficient to allow src.* to influence bin/Makefile and lib/Makefile etc without the need to touch them. Other customization hooks would be cool too, bsd.sys.mk is a somewhat unfortunate name, but it would be handy to have another point for including {src,local}.*.mk at the end of the normal lib,prog,* mk files. Note that even though we don't install src.*.mk or local.*.mk, those hook points are still very useful to anyone building their own stuff with bsd.*.mk, since now they can customize their own builds without the need to hack bsd.*.mk Thanks --sjg