From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 19:53:09 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 E145267D; Tue, 1 Apr 2014 19:53:09 +0000 (UTC) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) (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 95E0B2D6; Tue, 1 Apr 2014 19:53:09 +0000 (UTC) Received: from mail14-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.22; Tue, 1 Apr 2014 19:53:02 +0000 Received: from mail14-ch1 (localhost [127.0.0.1]) by mail14-ch1-R.bigfish.com (Postfix) with ESMTP id 7F50C40758; Tue, 1 Apr 2014 19:53:02 +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(zz1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h1082kzz1de097hz31h2a8h839hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h224fh1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h2218h2216h226dh22d0h24afh2327h2336h2381h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26d3h1155h) Received-SPF: softfail (mail14-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 mail14-ch1 (localhost.localdomain [127.0.0.1]) by mail14-ch1 (MessageSwitch) id 1396381980729658_29557; Tue, 1 Apr 2014 19:53:00 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail14-ch1.bigfish.com (Postfix) with ESMTP id A4DBB380108; Tue, 1 Apr 2014 19:53:00 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.239.11) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 1 Apr 2014 19:52:51 +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; Tue, 1 Apr 2014 12:52:50 -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 s31JqnV48957; Tue, 1 Apr 2014 12:52:49 -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 8752258097; Tue, 1 Apr 2014 12:52:49 -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> Comments: In-reply-to: Warner Losh message dated "Tue, 01 Apr 2014 12:57:57 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 1 Apr 2014 12:52:49 -0700 Message-ID: <20140401195249.8752258097@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: Tue, 01 Apr 2014 19:53:09 -0000 On Tue, 1 Apr 2014 12:57:57 -0600, Warner Losh writes: >> .if !defined(WITHOUT_CTF) && !defined(NO_CTF) >> WITH_CTF=3Dyes >> .endif >>=20 >> else you get errors during build world. > >That's a bug I plan on fixing. Agreed, and cool. >> That's not so much a problem for existing options, but makes it >> impractical to leverage the mechanism for things you might want to set >> during sys.mk - like whether to use meta mode or auto objdir creation. > >I=92ll have to think about this point. It is a good point, but I=92m = >unsure how >the proposed changes would fix that. Perhaps you could explain that a = >bit. Sure. For the sake of argument assume I can put something like this in local.sys.mk: OPTIONS_DEFAULT_NO+= \ META_MODE OPTIONS_DEFAULT_YES+= \ AUTO_OBJ .include "options.mk" .if ${MK_AUTO_OBJ} == "yes" .include "auto.obj.mk" .endif .if ${MK_META_MODE} == "yes" .include "meta.sys.mk" .endif and both MK_META_MODE={yes,no} MK_AUTO_OBJ={yes,no} which are needed during sys.mk can be influenced by user's -DWITH[OUT]_* >Setting defaults in make.conf, and then overriding them is tough because >bmake doesn't have a tracking system to know where in the food-chain >different variables are set. However, this is also a good point, but I >must be being dense to see how your proposal would fix this. It "fixes" it by not throwing an error when both WITH_FOO and WITHOUT_FOO are defined. Instead, you decree that one wins (eg WITHOUT_FOO overrides WITH_FOO). You could also address the conflict by giving preference to command line. ${.MAKEFLAGS:MWITH*} will give you any WITH_* and WITHOUT_* from command line. There might be a rare case where an error is desired on conflict, but if you can sensibly resolve it that is better. >> I have a number of knobs to be set during sys.mk >> AUTO_OBJ automatically create objdirs >> META_MODE use meta mode > >objdirs set in sys.mk? yes. >I thought that was done bad.obj.mk since it isn't part of the global system. Traditionally done in bsd.obj.mk - but that requires a separate invocation of make. The junos build for example has auto-created objdirs for 10+ years. The projects/bmake build does the same. It is a good way to ensure consistent/reliable results and avoid probelms when users forget to 'make obj'. When you have to support 2000+ developers you want to be able to make it hard for them to shoot themselves in the foot. If making objdirs automatically, you really want to do it early, since the result influences how make then behaves. >META_MODE might belong there. > >> setting MK_* is fine, but it is nice if you allow the user to interact >> using WITH[OUT]_*, and for that it is best if sys.mk can safely = >include >> something like options.mk > >Not sure how creating a new file solves the bsd.own.mk problem, apart >perhaps from some name space pollution differences. An options.mk which does nothing except process the list of options provided to it, is always safe to include even by sys.mk. Whereas bsd.own.mk does other stuff which makes it unsuitable to include eg. during the early stages of buildworld. bsd.own.mk can of course set its own list of options and then include the same options.mk a simple matter of refactoring to allow re-use. >Yea, back to the point I don=92t understand: how is your new file going = >to be >materially different than the current mechanism. I=92m OK with change, = >but I >need to understand how the change is going to make things better. Separating the mechanism of option processing from the definition of options makes re-use easier - see above, sorry I don't know how to make it clearer. The other aspects you have at least partially addressed already, by allowing MK_* to be set independently. Though: .if defined(MK_${var}) .if ${.MAKE.LEVEL} == 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_*? The outstanding question is dealing with conflict when both WITH_FOO and WITHOUT_FOO are defined. Thanks --sjg