From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 19:25:05 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 0CC2F89E for ; Tue, 1 Apr 2014 19:25:05 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 93886FBC for ; Tue, 1 Apr 2014 19:25:04 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w61so6848495wes.29 for ; Tue, 01 Apr 2014 12:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Zr/o8zRxGNWbsymSoHSbjUJIiomPxxiVl2EcxeG4VQg=; b=tS5A0dArxw6HWQTkvMFRsJgtGi4QG1iSl5797HlQF72OgWiGg64mdzuI2cZ0WsH/vb YgALAZN3qZqtwBOA66keFwJqQ/kX/gtrZpjMv00dNfpvRRyQLKYbdzRtUxFaIHifJ4pL otHXRQXccVjYQaCL9w4nUz37t7Ej8F7lNHjBWnaabRlnojr1qHbZRyF5WS52QRz/W1KI TSBuwhos6ugS/vJ6BjIY3gyee21gKVl4aElN7JeyDRgc1g3Qdch+Cx/81T3y/O83ghaA wnPu1q7RQ5rSA3RJuiy1p/6V/0PH+sC2W2EuMFWLcUb5Tc8V1rbKS8mm3RNOefKGdmgd s1mA== X-Received: by 10.180.103.227 with SMTP id fz3mr22374258wib.29.1396380302910; Tue, 01 Apr 2014 12:25:02 -0700 (PDT) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id pm5sm5761167wjc.11.2014.04.01.12.24.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Apr 2014 12:25:01 -0700 (PDT) Sender: Baptiste Daroussin Date: Tue, 1 Apr 2014 21:24:43 +0200 From: Baptiste Daroussin To: "Simon J. Gerraty" Subject: Re: make WITH[OUT]_* more useful? Message-ID: <20140401192443.GV99393@ivaldir.etoilebsd.net> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4QzzFpAwbwI4hdN6" Content-Disposition: inline In-Reply-To: <20140401162912.7A9D058097@chaos.jnpr.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arch@freebsd.org 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:25:05 -0000 --4QzzFpAwbwI4hdN6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 01, 2014 at 09:29:12AM -0700, Simon J. Gerraty wrote: >=20 > On Tue, 1 Apr 2014 08:22:18 -0600, Warner Losh writes: > >>> re-implement the WITH_* vs WITHOUT_* logic repeatedly. > > > >Where, exactly, do we do this? In my recent gripping I=3D92ve found almo= st >=20 > I hit this just about every possible way while trying to support > WITH[OUT]_BMAKE=20 > in such a way that people could build head on 9 etc. > Incluing in-tree bsd.own.mk so MK_BMAKE would get set - broke building > on 9 IIRC. >=20 > Being able to simply do MK_BMAKE?=3D {yes,no} would have been best soluti= on. >=20 > Also I normally want to built WITH_CTF, but of course you cannot simply > put that in make.conf you have to=20 >=20 > .if !defined(WITHOUT_CTF) && !defined(NO_CTF) > WITH_CTF=3Dyes > .endif >=20 > else you get errors during buildworld. >=20 > >>> It is also generally bad to include bsd.own.mk from sys.mk, which mea= ns > >>> any knobs you need early must re-implement the WITH_* vs WITHOUT_* lo= gic > >>> repeatedly. > > > >Again, I find no evidence of this in the tree, can you cite specific exa= mpl=3D >=20 > It isn't done anymore (was certainly done back in 2.x, don't recall when > it was removed), which is good, but means that sys.mk cannot use > any MK_* that the user can influence via WITH[OUT]_*. =20 > 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. >=20 > >I mostly hate this. Specifically, I don=3D92t like the DOMINANT bits. Th= ey ar=3D > >e unnecessary. >=20 > I mostly agree - I find it quite reasonable to simply allow WITHOUT to wi= n. > DOMINANT_* is just an "out" in case there's some future case I haven't > thought of. The default behavior remains that WITHOUT wins. >=20 > >WITH/WITHOUT is a user-only knob.=20 >=20 > Agreed, but the implementation renders it user unfriendly. > If everywhere I want to set a default (eg make.conf) I have to do a > dance like >=20 > .if !defined(WITHOUT_CTF) && !defined(NO_CTF) > WITH_CTF=3Dyes > .endif >=20 > it isn't exactly helping me as much as it could. > If the build stops using WITH/WITHOUT internally that probably helps. >=20 > >The build system should never use it, but always > >set MK_* directly.=20 >=20 > Agreed - that would be most useful and is one of the main changes in my > version. >=20 > >I recently fixed it so the build system can start doing =3D > >that. This solves > >the WITH and WITHOUT problem internally. >=20 > That's good - being able to set MK_* directly without causing error > does address the issue for the build itself. >=20 > Alone though it doesn't necessarily make life any better for users > who (per my example above) want to set defaults like > WITH_CTF=3D in make.conf but occasionally override them. Unless they too > are supposed to set MK_* directly but then what is the point of > WITH[OUT]_* ? >=20 > >I'm still not sure I see the big win. >=20 > I have a number of knobs to be set during sys.mk > AUTO_OBJ automatically create objdirs > META_MODE use meta mode >=20 > 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 >=20 > Of course the user can learn to MK_AUTO_OBJ=3Dno but that simply devalues > WITH[OUT]_*=20 >=20 > It is a neat mechanism, that with some minor tweaks could be much more > useful. >=20 > Baptiste writes: > >> I would be interested in having your opinion on what we did for ports. >=20 > It is a bit more elaborate (422 lines vs 59 in options.mk) > that's probably a necessity for ports, but not so sure about inclusion > by sys.mk >=20 >=20 >=20 >=20 >=20 it is more elaborate because it sets ports only things which is not needed = at all for src. It also handles compat with precious versions of options. Extracting the pure framework will lead to around 30 lines no more. and pro= bably way less. I can make a PoC if you want regards, Bapt --4QzzFpAwbwI4hdN6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlM7EnsACgkQ8kTtMUmk6ExJFgCgrSL1uGMr4GiESjMyTJEs7fcD dgQAnAtv81RIu7mAU0+BPiTAdBsCbk6b =ccaq -----END PGP SIGNATURE----- --4QzzFpAwbwI4hdN6--