From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 22:07:01 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 791892F9; Thu, 17 Apr 2014 22:07:01 +0000 (UTC) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) (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 2274218AD; Thu, 17 Apr 2014 22:07:00 +0000 (UTC) Received: from mail86-va3-R.bigfish.com (10.7.14.230) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Apr 2014 22:06:04 +0000 Received: from mail86-va3 (localhost [127.0.0.1]) by mail86-va3-R.bigfish.com (Postfix) with ESMTP id 91C94300396; Thu, 17 Apr 2014 22:06:04 +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(zz1432Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208ch1082kzz8275dh1de097hz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail86-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 mail86-va3 (localhost.localdomain [127.0.0.1]) by mail86-va3 (MessageSwitch) id 1397772362838083_15256; Thu, 17 Apr 2014 22:06:02 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.240]) by mail86-va3.bigfish.com (Postfix) with ESMTP id C3D813600D8; Thu, 17 Apr 2014 22:06:02 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.239.10) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Apr 2014 22:06:01 +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 15:06:44 -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 s3HM6XV02584; Thu, 17 Apr 2014 15:06:38 -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 242585809F; Thu, 17 Apr 2014 15:06:33 -0700 (PDT) To: Warner Losh Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: <7C527DA8-ABC0-4D6A-AACB-64D89246B569@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> <20140417181159.0EFEA5809E@chaos.jnpr.net> <7C527DA8-ABC0-4D6A-AACB-64D89246B569@bsdimp.com> Comments: In-reply-to: Warner Losh message dated "Thu, 17 Apr 2014 14:29:28 -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 15:06:33 -0700 Message-ID: <20140417220633.242585809F@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 22:07:01 -0000 On Thu, 17 Apr 2014 14:29:28 -0600, Warner Losh writes: >> bsd.own.mk -> bsd.srcopts.mk -> bsd.mkopts.mk > >Since we=92re planning a src.opts.mk at some point (to control /usr/src bui= >lds), >the bsd.srcopts.mk name seems to have a short shelf life. Maybe just bsd.op= >ts.mk? Sure bsd.opts.mk sounds fine. >> .-include "src.sys.mk" >> .-include "local.sys.mk" >> = > >> that would be sufficient to enable all sorts of cool stuff. > >In non-posix mode, sure. This would be the natural place for >the MK option setting. While it is early, it isn=92t too bad. It works >great for buildworld scenarios, since we have a well-defined >location for src.sys.mk. It works less well for the individual src >Makefiles that might need to access variables set in src.sys.mk, >which becomes unfindable w/o extra args on the command line, >or requires knowledge of where the Makefile lives in the tree >to reach over and snag it. I've avoided that issue for ages by using a wrapper script to condition the env for the tree I'm working in, junos freebsd, netbsd etc. If all your trees have a share/mk, that you want to use you can just export MAKESYSPATH=".../share/mk" and bmake will DTRT. >> 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. = > >What would go there? Or would they be empty place holders? It depends. Some things need to be done after Makefile has been read (rather than before) - eg any variable ref on rhs of dependency rule needs to have a value at that time. Let's say I wanted to be able to build head in meta mode (rather than keep syncing to projects/bmake). If there were suitable local.*.mk hook points I could do that without affecting anyone else, until such time as I can convince others that its a brilliant idea ;-) Even if FreeBSD.org decide they want to build /usr/src in meta mode, that doesn't mean that every user of FreeBSD wants all their own projects to build that way. Some of the glue I had in local.*.mk could move to src.*.mk so that /usr/src could leverage it without impacting every user of bsd.*.mk That's just one example of course. >Also missing is a defined place for users to define WITH/WITHOUT_FOO. You can still support {src,local,make}.conf >True, but it looks like it may make in-tree use in the non-build-world case= > more complicated. There may be some resistance to that. I'm not sure it would impact one way or the other. It all boils down to whether /usr/share/mk, -m * or $MAKESYSPATH are used. I would figure anyone inclined to go adding local.*.mk to their tree, would be able to cope with setting MAKESYSPATH or whatever else it takes to do what they want. Thanks --sjg