From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 18:58:01 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEEDB12F for ; Tue, 1 Apr 2014 18:58:01 +0000 (UTC) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 8F3FED3E for ; Tue, 1 Apr 2014 18:58:01 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id kq14so10270904pab.37 for ; Tue, 01 Apr 2014 11:58:00 -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=ep8exWb1lFv+AunpPzCNvkzew7r+YL1GoqfBDATXms8=; b=SP3YrJDQJ3lV2VBeagQRIv2GYLTXppT3R+2xymh5LrZA+MNxCr01iJGmSfBEfDemiS KQFo7jf6zymBp5eZYtQOfi41BRuYq97zyucOTWdz5wFjWhQOUmh9ofuLoEtTOs6Qf+zD VhPtdqfySSQzJLTHG0h4JpocD7O7tufc4D53gFWJ0hfJwc+sBGzTabepX3e6l7oazWgI bI/TJdIlp7LUWvKntuIbmFrw2QPG+2nkGfxAy2t60Me2iCLS/XkuqyXeirGuy8bN6GWr FWGHJzd1tnDpzygKhUEUENZVxX/5IH2ZydHJ51VLPkjGp67jnmcFx0eth5HE/Yh+xXVd CUkQ== X-Gm-Message-State: ALoCoQl6bxh8JIr0L5pwcudC/+JLeRaavW0/q4tm+a3lvL7QdSXyMWfQRdd/McLJyLw/KRaCsrJ2 X-Received: by 10.66.146.105 with SMTP id tb9mr3459836pab.157.1396378680783; Tue, 01 Apr 2014 11:58:00 -0700 (PDT) Received: from [10.64.24.154] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id aj7sm59696490pad.29.2014.04.01.11.57.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 11:58:00 -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: <20140401162912.7A9D058097@chaos.jnpr.net> Date: Tue, 1 Apr 2014 12:57:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> <20140401162912.7A9D058097@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: Tue, 01 Apr 2014 18:58:01 -0000 On Apr 1, 2014, at 10:29 AM, 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. >>=20 >> Where, exactly, do we do this? In my recent gripping I=3D92ve found = almost >=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 = solution. >=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 build world. That=92s a bug I plan on fixing. But an interesting one because much of = the extra garbage there is due to the duality in the build system where we bogusly = (IMHO) set WITHOUT_CTF on the make command line, plus have an extra special NO_CTF option which does the same sort of thing. Bugs in bmake prevent the simple undefining of certain symbols on the = command line, which makes at least part of the above construct necessary. >>>> It is also generally bad to include bsd.own.mk from sys.mk, which = means >>>> any knobs you need early must re-implement the WITH_* vs WITHOUT_* = logic >>>> repeatedly. >>=20 >> Again, I find no evidence of this in the tree, can you cite specific = exampl=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. 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. >> I mostly hate this. Specifically, I don=3D92t like the DOMINANT bits. = They ar=3D >> e unnecessary. >=20 > I mostly agree - I find it quite reasonable to simply allow WITHOUT to = win. > 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. Yea, that=92s just a bug=85 We have severe options like this, but CTF is = one of the more annoying. >> 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. Already in the tree. >> 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]_* ? 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. >> 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 objdirs set in sys.mk? I thought that was done bad.obj.mk since it isn=92t= part of the global system. 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. > 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. It is neat and simple now, but the WITH/WITHOUT stuff was neat and = simple when we started and it has devolved as people have hacked on it without proper care. > 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 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. Warner