From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 14:22:22 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 706435EA for ; Tue, 1 Apr 2014 14:22:22 +0000 (UTC) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (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 41FA1A2A for ; Tue, 1 Apr 2014 14:22:21 +0000 (UTC) Received: by mail-pd0-f176.google.com with SMTP id r10so9566157pdi.7 for ; Tue, 01 Apr 2014 07:22:21 -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=JQW4rEOlfUPXsYL+wsv/KbEs+3UOghKgZc/Qawnbqyg=; b=XfyZQu8oq7T+wopJhu8YFsUCkRDEtEWDJtGDVgbBquT/6D1IiC/n0lEH3wzJYqwH3O Ey3Cg7Z1ORMMnhsIB1sJg1HNjaTEqQp+oXbSl5XTEyiV/ZGV3sHU1KXZY6+73MaHfa1t YIIxNyBic3l7TJfHu8UO7GKlTRYDcwB7ErJRMqiRLR95ignwAJc/FLWtudAe8WlpSVkH A8G4x7QntDFR4Zeuf3kZ6DjD4+vOrHvZBdyb/XSrzf2jkHhPUpP60/LFAzBy322g9VLz DLKMoQDIAcsg1jgzT9zhDy5/Ek2rbZ8+t+mb4x9pUeFXyR34G22ZHjTAwJbqz53Gbg44 UWMw== X-Gm-Message-State: ALoCoQlk+eOpTtEuNzG2k/Ux6HHuNGUe8dtesA2H27hgn4ARUPtvtMDDJ5YNtyBDUJDaZX3ecTIp X-Received: by 10.66.163.2 with SMTP id ye2mr15576578pab.110.1396362141462; Tue, 01 Apr 2014 07:22:21 -0700 (PDT) Received: from [10.64.26.254] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id my6sm50345980pbc.36.2014.04.01.07.22.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 07:22:20 -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: <20140401064316.GQ99393@ivaldir.etoilebsd.net> Date: Tue, 1 Apr 2014 08:22:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1874) Cc: freebsd-arch@freebsd.org, Simon Gerraty 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 14:22:22 -0000 On Apr 1, 2014, at 12:43 AM, Baptiste Daroussin = wrote: > On Mon, Mar 31, 2014 at 10:13:27PM -0700, Simon Gerraty wrote: >> I really like the idea of WITH[OUT]_* knobs translating to MK_* = knobs, >> but I find the current implementation much less useful than I think = it >> could be. Not the least of its problems is being implemented in >> bsd.own.mk which ties policy and mechanism together. >>=20 >> It is not always (rarely) safe to include the in-tree bsd.own.mk = which >> means that in many cases you cannot rely on MK_* at all, but have to >> re-implement the WITH_* vs WITHOUT_* logic repeatedly. Where, exactly, do we do this? In my recent gripping I=92ve found almost no instances of this. The ones I did find were trivial to fix, and I = have either committed or will commit fixes for them. So perhaps you could come up with an actual example of the problem you are talking about. >> 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. Again, I find no evidence of this in the tree, can you cite specific = examples? I=92ve been going through the tree fixing many abuses that did this = when, in fact, they didn=92t need to. >> contrib/bmake/mk/options.mk is an example of a more generic >> implementation with (I think) some advantages. >>=20 >> The key semantic changes are (DOMINANT_* is from a newer version >> than in contrib): >>=20 >> # NO_* takes precedence >> # If both WITH_* and WITHOUT_* are defined, WITHOUT_ wins unless >> # DOMINANT_* is set to "yes" >> # Otherwise WITH_* and WITHOUT_* override the default. >> and >> MK_* can be pre-set without causing an error. I mostly hate this. Specifically, I don=92t like the DOMINANT bits. They = are unnecessary. WITH/WITHOUT is a user-only knob. The build system should never use it, = but always set MK_* directly. I recently fixed it so the build system can start = doing that. This solves the WITH and WITHOUT problem internally. I have a round of changes that I=92m pushing in this morning once I = check to make sure that universe completed on them successfully. >> The key advantage is that the mechanism is separate from the policy. >> You can thus have knobs that get set much earlier (eg during sys.mk) >> and other knobs that get set later. Ie. both sys.mk and bsd.own.mk = can >> include options.mk to process options that they care about, allowing >> MK_* to be used more consistently - you could use different prefix to >> avoid overlap, but that's probably not necessary. I=92m still not sure I see the big win. >> You can in fact have per-makefile option lists if you want (see >> contrib/bmake/Makefile)=20 Since the base system is supposed to be one, integrated whole, I=92m not = sure what this will buy you... >> Thoughts? >=20 > I would be interested in having your opinion on what we did for ports. >=20 > Basically we have in the end a variable: PORT_OPTIONS that contains = the the > options that are considered like "MK_*" =3D yes and all the one = considerer as > are not it. There is overlap in concept between the PORT_OPTIONS, but the MK/NO = knobs control more fundamental and sometimes global options to the build. = Also, there are thousands of instances of PORT_OPTIONS in a large port build, one = for each port. We have one set for the src tree. > one can activate variables via make.conf: > OPTIONS_SET=3D OPT1 OPT2 > OPTIONS_UNSET=3D OPT3 >=20 > We added a couple of sugar so that options are not on yes/no but can = be a > selection in a list etc. >=20 > Can be looked at here: = http://svnweb.freebsd.org/ports/head/Mk/bsd.options.mk >=20 > Having it creating in the end the MK_* variables would be really realy = easy. This is a potentially interesting concept, but I don=92t think it scales = well to the src tree. Warner