Date: Mon, 31 Mar 2014 22:13:27 -0700 From: Simon Gerraty <sjg@juniper.net> To: <freebsd-arch@freebsd.org> Cc: sjg@juniper.net Subject: make WITH[OUT]_* more useful? Message-ID: <20140401051327.F20F958097@chaos.jnpr.net>
next in thread | raw e-mail | index | archive | help
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. 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. 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. contrib/bmake/mk/options.mk is an example of a more generic implementation with (I think) some advantages. The key semantic changes are (DOMINANT_* is from a newer version than in contrib): # 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. 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. You can in fact have per-makefile option lists if you want (see contrib/bmake/Makefile) Thoughts?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140401051327.F20F958097>