From owner-freebsd-arch@FreeBSD.ORG Wed Apr 9 21:13:43 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 2FA3458E for ; Wed, 9 Apr 2014 21:13:43 +0000 (UTC) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) (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 F26181145 for ; Wed, 9 Apr 2014 21:13:42 +0000 (UTC) Received: by mail-pd0-f182.google.com with SMTP id y10so2950842pdj.27 for ; Wed, 09 Apr 2014 14:13:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=g1TBZZ58RJtzGWfbkEfRcViZI1SNvfbEdDR0AsDgUN4=; b=Z1E6zD21TzgW+JIwDzD77mhlPe06klWO2a24SR/lzCQN1IJjy+/xyoSFfLK9fw8BFs fqO4a2WWYezBohOR1nWYG8F1SGQYz1YTuUlhcQ2pzZzJlnjmZtPFLel1ZFpR979cB+AG zeNEo1D8PcQdi9g8TY6ftmJ1N48NYbnxKyqdpe+R1rwu9A8HA5T8wQ4X1byf8bv9uwUE wq+bbpY0QJV1zsKFb+fK0vyoqA44VfABJUdDyToEPVEaeEhn4mU9tA1Ls4JblnFcayl9 TZNdp/W/yproOJDfzXvDDyZOmfd1T7lwMUuKK2gEeCNPSyllqbF+QJifI2yd5guGpJRj /ExQ== X-Gm-Message-State: ALoCoQlMoaii4k6UwFsi1LsA0slNjKgA0AWuHUNxxa5zsAg3wbWwOKl0qQNSixBqUqat3pn77/CA X-Received: by 10.66.142.201 with SMTP id ry9mr14969367pab.14.1397078015959; Wed, 09 Apr 2014 14:13:35 -0700 (PDT) Received: from [10.64.24.116] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id dn1sm4541569pbb.54.2014.04.09.14.13.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 14:13:35 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: make WITH[OUT]_* more useful? From: Warner Losh In-Reply-To: <20140402212328.7CE8958097@chaos.jnpr.net> Date: Wed, 9 Apr 2014 15:13:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5D9BD168-D7E5-477E-AEA3-47B24445C89F@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> To: "Simon J. Gerraty" X-Mailer: Apple Mail (2.1874) Cc: Baptiste Daroussin , 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: Wed, 09 Apr 2014 21:13:43 -0000 Hi Simon, Sorry to take a week to reply. Other things came up and it slipped my = mind until now. It sounds like we=92re in agreement on how to proceed, or very nearly = so. I have some more comments below, but I think the next order of business would be patches. = Do you have some ready to roll? If so, then we should iterate on them. If not, I can = find some time over the coming days/weeks. I=92d like to have this done before BSDcan, but = if not we can chat then, assuming you are going. On Apr 2, 2014, at 3:23 PM, Simon J. Gerraty wrote: >>> which are needed during sys.mk can be influenced by user's = -DWITH[OUT_* >>=20 >> OK. A bit of a contrived example, but I suppose if I understood the = meta mo=3D >> de >=20 > Actually not contrived at all - we have that internally. > Ie. we have a local.sys.mk to set all our cool stuff > but we currently just test for .ifdef WITH[OUT]*, hence this thread. Makes sense... >> a bit better I might think differently :) >>=20 >> I=3D92m a bit hesitant, though, to have this affect sys.mk because = that affec=3D >> ts all users >> of make, not just /usr/src. >=20 > That's why I'd put such things in local.sys.mk or some other makefile > that affects /usr/src but isn't install into /usr/share/mk/ That=92s a bit of a departure over how we=92ve done things, but one that = may make a good amount of sense. Where would the src build pick this up from if = it isn=92t installed? >> In some cases, you can declare a winner. In other cases that might be = harder >> to do. With almost all options defaulting to YES, having WITHOUT win = makes >> good sense. When there=3D92s more of a mix, I=3D92m less sure. >=20 > Agreed, that's why I took the easy way out by allowing the winner to = be > configured if the need should arise ;-) >=20 >>> Traditionally done in bsd.obj.mk - but that requires a separate >>> invocation of make. >>=20 >> Right, but can=3D92t that be done automatically w/o that extra = invocation? >=20 > Yes provided you do it early enough (ie during sys.mk) > eg. before you've evaluated things that affect .PATH Ah, I was aware of that restriction. >> Back to the NO_CTF stuff I talked about above: I totally get this. If = you l=3D >=20 >> There=3D92s one place in the tree that wants to turn off CTF. This is = mostly =3D >> fixed by >> just setting MK_CTF=3D3Dno in that makefile after we include = bsd.own.mk. I say >=20 > Wouldn't it be simpler to set MK_CTF=3Dno *before* including = bsd.own.mk ? Well, kinda=85 Then the issue becomes, in what I think you are = proposing, what happens to the meta variables, or MK_foo that sets a lot of MK_bar. Assuming we = move all of them to their own file, we have two sections. One that sets MK_xxx = variables based on WITH/WITHOUT, and a second one that sets them based on other MK_xxx = variables. If I set MK_CTF=3Dno in my makefile, and it caused other MK_ flags to be = set, then I=92d have to include something to take another run at setting those = meta-variables. >> mostly fixed because we wind up with a NULL command where we really = want >> a @: command, though the former I believe is harmless but verbose. = Except >> one could unset WITH_CTF (which doesn=3D92t completely work, it still = shows >> up as defined) and set WITHOUT_CTF before bsd.own.mk and it would = work, >> modulo this bug. >>=20 >> This can really only be fixed by making bsd.own.mk look more like >>=20 >> # section 1 -same >> .include >> # section 3 - same >>=20 >> with bsd.options.mk looking a lot like section 2 of bsd.own.mk. = Also, we=3D >> =3D92d have >=20 > Yes, that's essentially what I was proposing. > By extracting the mechanism to its own file, it can be re-used. Do you have patches? I think I like it... >> This sounds a lot like what you=3D92re trying to describe, though = placement of >> bsd.options.mk may be different than I described. The only reason we >> need it where I suggested it is compatibility with the past. Though = we may >=20 > Yes I assumed it would be included as above - to avoid changing = behavior > unnecessarily. Note: tweaking the semantics and making it re-usable = are > somewhat orthogonal. Yes. I can=92t fix MK_CTF without a fix due to side effects. >> be able to get away with it in sys.mk, I=3D92m hesitant to place it = in there =3D >> because >> that=3D92s global to everything, including ports, etc. Plus, I think = it is to=3D >=20 > Calling it bsd.options.mk is a conflict with ports. > Though including it as "bsd.options.mk" both in bsd.own.mk and in the > relevant ports makefile, should probably mitigate that. I thought ports used a different mechanism and defined special magic so = the src tree mechanism was disabled. >> o early, due to meta MK_ variables, that I talk about below. >=20 >>> .if defined(MK_${var}) >>> .if ${.MAKE.LEVEL} =3D3D=3D3D 0 >>> .error MK_${var} can't be set by a user. >>> .endif >>> =3D >>=20 >>> would seem to negate that. Why can a makefile at level 0 not set = MK_*? >>=20 >> Well, the notion now is that if you want to test MK_* variables, you = need to >> include bsd.own.mk first. The notion I was going for with the above = is that=3D >=20 > Setting MK_* before bsd.own.mk vs after has semantic differences > but that shouldn't preclude doing either. >=20 > Eg. the knob names below describe the semantics >=20 > # these remove choice from user > MK_CANNOT=3D no > MK_MUST=3D yes >=20 > .include >=20 > # these respect user choices > MK_LIKE?=3D yes > MK_DISLIKE?=3D no >=20 >> But there=3D92s a problem even if we take the approach above. Section = 2 in bs=3D >> d.own.mk >> is actually two separate sections. One that sets the MK_* variables = based on >> WITH_ or WITHOUT_ and then a second section that cascades the MK_ = variables >> to other MK_ variables (like MK_CRYPT=3D3D=3D3Dno turning of OpenSSL, = Kerberos,=3D >> etc). If >> you wanted to set one of those variables in your Makefile, you=3D92d = have a c=3D >> hicken >> and egg problem. If you set it before bsd.options.mk, then you=3D92d = get the =3D >> cascade effects >> but hit the warning. If you set it after, you dodge the warning, but = don=3D92=3D >> t get the cascade. >=20 > Per above setting MK_* before including bsd.own.mk is just supressing > user input, probably not something to do a lot, but handy at times - > eg. allows doing away with NO_* >=20 > If that has cascading effects, we assume they are intended. >=20 > Currently, what warning do you hit btw?=20 > I only see .errors if MK_* is pre-defined or WITH[OUT]* both defined. Those errors, although many have been corrected... >> This problem suggests, perhaps, that the test be deleted. >>=20 >>> The outstanding question is dealing with conflict when both WITH_FOO = and >>> WITHOUT_FOO are defined. >>=20 >> True. That=3D92s a tougher problem than you might think on first = blush, as we=3D >> =3D92ve >> been talking about. For now, I=3D92d suggest WITHOUT wins, and we see = how far >=20 > Agreed. I cannot currently think of a case where that wouldn't be > right, but as I mentioned wrt my options.mk it is easy to allow > configurability should the need arise. I=92m agnostic on a mechanism to declare winners. If we can do the rest = easily w/o it I don=92t care. If it is just a couple of lines to add, I won=92t = complain. Warner