make WITH[OUT]_* more useful?

[Warner Losh]

On Apr 1, 2014, at 12:43 AM, Baptiste Daroussin <bapt at 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.
>> 
>> 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’ve 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’ve been going through the tree fixing many abuses that did this when, in fact,
they didn’t need to.

>> 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.

I mostly hate this. Specifically, I don’t 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’m 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’m still not sure I see the big win.

>> You can in fact have per-makefile option lists if you want (see
>> contrib/bmake/Makefile) 

Since the base system is supposed to be one, integrated whole, I’m not sure
what this will buy you...

>> Thoughts?
> 
> I would be interested in having your opinion on what we did for ports.
> 
> Basically we have in the end a variable: PORT_OPTIONS that contains the the
> options that are considered like "MK_*" = 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= OPT1 OPT2
> OPTIONS_UNSET= OPT3
> 
> We added a couple of sugar so that options are not on yes/no but can be a
> selection in a list etc.
> 
> Can be looked at here: http://svnweb.freebsd.org/ports/head/Mk/bsd.options.mk
> 
> Having it creating in the end the MK_* variables would be really realy easy.

This is a potentially interesting concept, but I don’t think it scales well to the src
tree.

Warner