make WITH[OUT]_* more useful?

[Warner Losh]

Hi Simon,

Sorry to take a week to reply. Other things came up and it slipped my mind until now.

It sounds like we’re in agreement on how to proceed, or very nearly so. I have some more
comments below, but I think the next order of business would be patches. Do you have
some ready to roll? If so, then we should iterate on them. If not, I can find some time over
the coming days/weeks. I’d like to have this done before BSDcan, but if not we can
chat then, assuming you are going.

On Apr 2, 2014, at 3:23 PM, Simon J. Gerraty <sjg at juniper.net> wrote:

>>> which are needed during sys.mk can be influenced by user's -DWITH[OUT_*
>> 
>> OK. A bit of a contrived example, but I suppose if I understood the meta mo=
>> de
> 
> Actually not contrived at all - we have that internally.
> Ie. we have a local.sys.mk to set all our cool stuff
> but we currently just test for .ifdef WITH[OUT]*, hence this thread.

Makes sense...

>> a bit better I might think differently :)
>> 
>> I=92m a bit hesitant, though, to have this affect sys.mk because that affec=
>> ts all users
>> of make, not just /usr/src.
> 
> That's why I'd put such things in local.sys.mk or some other makefile
> that affects /usr/src but isn't install into /usr/share/mk/

That’s a bit of a departure over how we’ve done things, but one that may make
a good amount of sense. Where would the src build pick this up from if it isn’t
installed?

>> In some cases, you can declare a winner. In other cases that might be harder
>> to do. With almost all options defaulting to YES, having WITHOUT win makes
>> good sense. When there=92s more of a mix, I=92m less sure.
> 
> Agreed, that's why I took the easy way out by allowing the winner to be
> configured if the need should arise ;-)
> 
>>> Traditionally done in bsd.obj.mk - but that requires a separate
>>> invocation of make.
>> 
>> Right, but can=92t that be done automatically w/o that extra invocation?
> 
> Yes provided you do it early enough (ie during sys.mk)
> eg. before you've evaluated things that affect .PATH

Ah, I was aware of that restriction.

>> Back to the NO_CTF stuff I talked about above: I totally get this. If you l=
> 
>> There=92s one place in the tree that wants to turn off CTF. This is mostly =
>> fixed by
>> just setting MK_CTF=3Dno in that makefile after we include bsd.own.mk. I say
> 
> Wouldn't it be simpler to set MK_CTF=no *before* including bsd.own.mk ?

Well, kinda… Then the issue becomes, in what I think you are proposing, what happens
to the meta variables, or MK_foo that sets a lot of MK_bar. Assuming we move all of
them to their own file, we have two sections. One that sets MK_xxx variables based on
WITH/WITHOUT, and a second one that sets them based on other MK_xxx variables.
If I set MK_CTF=no in my makefile, and it caused other MK_ flags to be set, then I’d have
to include something to take another run at setting those meta-variables.

>> mostly fixed because we wind up with a NULL command where we really want
>> a @: command, though the former I believe is harmless but verbose. Except
>> one could unset WITH_CTF (which doesn=92t completely work, it still shows
>> up as defined) and set WITHOUT_CTF before bsd.own.mk and it would work,
>> modulo this bug.
>> 
>> This can really only be fixed by making bsd.own.mk look more like
>> 
>> # section 1 -same
>> .include <bsd.options.mk>
>> # section 3 - same
>> 
>> with bsd.options.mk looking a lot like section 2 of bsd.own.mk.  Also, we=
>> =92d have
> 
> Yes, that's essentially what I was proposing.
> By extracting the mechanism to its own file, it can be re-used.

Do you have patches? I think I like it...

>> This sounds a lot like what you=92re trying to describe, though placement of
>> bsd.options.mk may be different than I described. The only reason we
>> need it where I suggested it is compatibility with the past. Though we may
> 
> Yes I assumed it would be included as above - to avoid changing behavior
> unnecessarily.  Note: tweaking the semantics and making it re-usable are
> somewhat orthogonal.

Yes. I can’t fix MK_CTF without a fix due to side effects.

>> be able to get away with it in sys.mk, I=92m hesitant to place it in there =
>> because
>> that=92s global to everything, including ports, etc. Plus, I think it is to=
> 
> Calling it bsd.options.mk is a conflict with ports.
> Though including it as "bsd.options.mk" both in bsd.own.mk and in the
> relevant ports makefile, should probably mitigate that.

I thought ports used a different mechanism and defined special magic so the
src tree mechanism was disabled.

>> o early, due to meta MK_ variables, that I talk about below.
> 
>>> .if defined(MK_${var})
>>> .if ${.MAKE.LEVEL} =3D=3D 0
>>> .error MK_${var} can't be set by a user.
>>> .endif
>>> =
>> 
>>> would seem to negate that.  Why can a makefile at level 0 not set MK_*?
>> 
>> Well, the notion now is that if you want to test MK_* variables, you need to
>> include bsd.own.mk first. The notion I was going for with the above is that=
> 
> Setting MK_* before bsd.own.mk vs after has semantic differences
> but that shouldn't preclude doing either.
> 
> Eg. the knob names below describe the semantics
> 
> # these remove choice from user
> MK_CANNOT= no
> MK_MUST= yes
> 
> .include <bsd.own.mk>
> 
> # these respect user choices
> MK_LIKE?= yes
> MK_DISLIKE?= no
> 
>> But there=92s a problem even if we take the approach above. Section 2 in bs=
>> d.own.mk
>> is actually two separate sections. One that sets the MK_* variables based on
>> WITH_ or WITHOUT_ and then a second section that cascades the MK_ variables
>> to other MK_ variables (like MK_CRYPT=3D=3Dno turning of OpenSSL, Kerberos,=
>> etc). If
>> you wanted to set one of those variables in your Makefile, you=92d have a c=
>> hicken
>> and egg problem. If you set it before bsd.options.mk, then you=92d get the =
>> cascade effects
>> but hit the warning. If you set it after, you dodge the warning, but don=92=
>> t get the cascade.
> 
> Per above setting MK_* before including bsd.own.mk is just supressing
> user input, probably not something to do a lot, but handy at times -
> eg. allows doing away with NO_*
> 
> If that has cascading effects, we assume they are intended.
> 
> Currently, what warning do you hit btw? 
> I only see .errors if MK_* is pre-defined or WITH[OUT]* both defined.

Those errors, although many have been corrected...

>> This problem suggests, perhaps, that the test be deleted.
>> 
>>> The outstanding question is dealing with conflict when both WITH_FOO and
>>> WITHOUT_FOO are defined.
>> 
>> True. That=92s a tougher problem than you might think on first blush, as we=
>> =92ve
>> been talking about. For now, I=92d suggest WITHOUT wins, and we see how far
> 
> Agreed.  I cannot currently think of a case where that wouldn't be
> right, but as I mentioned wrt my options.mk it is easy to allow
> configurability should the need arise.

I’m agnostic on a mechanism to declare winners. If we can do the rest easily w/o
it I don’t care. If it is just a couple of lines to add, I won’t complain.

Warner