make WITH[OUT]_* more useful?

[Simon J. Gerraty]

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

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

>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

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

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

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

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

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

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

Thanks
--sjg