make WITH[OUT]_* more useful?

Simon Gerraty sjg at juniper.net
Tue Apr 1 05:13:40 UTC 2014


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?



More information about the freebsd-arch mailing list