Date: Tue, 1 Apr 2014 08:22:18 -0600 From: Warner Losh <imp@bsdimp.com> To: Baptiste Daroussin <bapt@FreeBSD.org> Cc: freebsd-arch@freebsd.org, Simon Gerraty <sjg@juniper.net> Subject: Re: make WITH[OUT]_* more useful? Message-ID: <766EFF76-7B41-423F-B447-DBA25BD14470@bsdimp.com> In-Reply-To: <20140401064316.GQ99393@ivaldir.etoilebsd.net> References: <20140401051327.F20F958097@chaos.jnpr.net> <20140401064316.GQ99393@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 1, 2014, at 12:43 AM, Baptiste Daroussin <bapt@FreeBSD.org> = 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?766EFF76-7B41-423F-B447-DBA25BD14470>