From owner-freebsd-arch@FreeBSD.ORG Thu Apr 17 06:34:55 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 46DCECA9; Thu, 17 Apr 2014 06:34:55 +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 E670D1BCC; Thu, 17 Apr 2014 06:34:54 +0000 (UTC) Received: from mail229-va3-R.bigfish.com (10.7.14.226) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Apr 2014 06:34:10 +0000 Received: from mail229-va3 (localhost [127.0.0.1]) by mail229-va3-R.bigfish.com (Postfix) with ESMTP id 279A1B6041F; Thu, 17 Apr 2014 06:34:10 +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: 3 X-BigFish: VPS3(zz1dbaI1432Izz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208ch1082kzz17326ah8275dh1de097h186068h74efjz31h2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail229-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 mail229-va3 (localhost.localdomain [127.0.0.1]) by mail229-va3 (MessageSwitch) id 1397716447695681_27985; Thu, 17 Apr 2014 06:34:07 +0000 (UTC) Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.245]) by mail229-va3.bigfish.com (Postfix) with ESMTP id A6D2134007B; Thu, 17 Apr 2014 06:34:07 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.239.10) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Apr 2014 06:34:07 +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; Wed, 16 Apr 2014 23:34:49 -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 s3H6YbV60659; Wed, 16 Apr 2014 23:34:43 -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 3BBF85809E; Wed, 16 Apr 2014 23:34:37 -0700 (PDT) To: Warner Losh Subject: Re: make WITH[OUT]_* more useful? In-Reply-To: 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> Comments: In-reply-to: Warner Losh message dated "Tue, 15 Apr 2014 20:27:49 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 16 Apr 2014 23:34:37 -0700 Message-ID: <20140417063437.3BBF85809E@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 06:34:55 -0000 >> I'm obviously biased, but I think contrib/bmake/mk/options.mk is close >> to what is desired - just the mechanism with no policy. > >I=92ve created a bsd.srcopt.mk and adjusted bsd.own.mk in a sample patch, s= >ince >it sounds like we=92re headed in the right direction. Please take a look at= > it and >let me know what you think. Thanks >http://people.freebsd.org/~imp/patch-queue/bsd.srcopt.mk > >contains the patch and commit message (if I did the queue management right) >that I=92d like to proffer. I could be miss-reading this, but it looks like you moved the list of options to bsd.srcopt.mk ? That's not what I was suggesting, though I can see how it might be useful. I was specifically thinking of a makefile that does not define/know any options at all. You set a list of options and include it and it does the WITH[OUT]_* -> MK_* dance. Eg. contrib/bmake/mk/options.mk consumes OPTIONS_DEFAULT_* but does not set even a default list. If you include it with no options list, it does nothing - pure mechanism. Now it might be very useful to extract the list of src options from bsd.own.mk to something safer to include anytime. But it is still (I think) useful to separate the options processing from their definition. Eg. something like: bsd.own.mk .include defines a bunch of options .include sets MK_* based on WITH[OUT]_* for the list of options provided or per my comments below about installing, perhaps the list of options etc might be better in src.options.mk (ie something we don't install? I just thought of that so take with grain of salt) Regardless, it might be handy to see the full files, to get a clearer picture. >earlier in this thread. I=92m not tied to what I=92ve posted here, but I wo= >uld >like to reach resolution so I can fix some other things in the build without >much delay. Sure. > >>> Where would the src build pick this up from if =3D >>> it isn=3D92t installed? >> = > >> src/share/mk should work fine. > >OK. I haven=92t added it to the Makefile so it gets installed, and things >seem to build, but that=92s not a viable way to commit things. Please comme= >nt >on what I=92ve done and what you think the right way to proceed might be. >The easy path is, of course, just installing it :) Sorry, which file are you talking about? 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. To restate that slightly differently, you can think of these things as a hierarchy: bsd.* mechanism for building stuff (not just /usr/src) src.* stuff just for building /usr/src local.* local tweaks to all the above >> Not necessarily. The stuff in bsd.own.mk like: >> = > >> .if ${MK_TOOLCHAIN} =3D=3D "no" >> MK_BINUTILS:=3D no >> MK_CLANG:=3D no >> MK_GCC:=3D no >> MK_GDB:=3D 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. > >That might be hard, since MK_FOO being set from the first time won=92t Unless MK_FOO is set on make's commandline, you can override it any time you like - whether that makes sense or whether it gives people headaches is another matter. Most of the current options seem to be more about whether certain features/apps etc should be built. Changing the value of such options once set doesn't make a lot of sense. eg. no point building libfoo without support for goop, and then building food with a need for it. The sorts of knobs more likely to be useful to tweak as we go, are those that affect how we do building (cf. configuring src), so MK_CTF, MK_META_MODE, and probably many others we could come up with if the mechanism were sufficiently flexible and easy to grok. >> No, but could do so pretty quickly. Sorry I lied... ;-) >I opted for a different name to not conflict. Probably best. Thanks --sjg