make WITH[OUT]_* more useful?

[Simon J. Gerraty]

>It sounds like we=92re 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? 

No, not yet - I figured getting some level of consensus fist was
worthwhile.

My cunning plan was simply to remove the mechanism from bsd.own.mk,
and include the new file at approximately the original location.
Thus not necessarily any functional change.
The devil's in the details of course.

I'm obviously biased, but I think contrib/bmake/mk/options.mk is close
to what is desired - just the mechanism with no policy.

>If so, then we should iterate on them. If not, I can =
>find some time over
>the coming days/weeks. I=92d like to have this done before BSDcan, but =
>if not we can
>chat then, assuming you are going.

Sounds good, yes I'll be there.

>> 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=92s a bit of a departure over how we=92ve done things, but one that =
>may make a good amount of sense. 

I've been distributing my *.mk files for a long time, and I prefer
people leave them as is, so I make it easy for them to customize without
hacking.  Adding .-include "local.*.mk" allows for a lot of
customization.
When I wrote dirdeps.mk et al it was with the understanding that Juniper
would make them publicly available, so used the same model.

IIRC there was some discussion at dev summit or BSDCan last year about
having src/ look for src.conf, make.conf etc inside the tree rather than
/etc.  I know in our internal builds we want to ensure that our src/ is
self contained.

>Where would the src build pick this up from if =
>it isn=92t installed?

src/share/mk should work fine.

>> Wouldn't it be simpler to set MK_CTF=3Dno *before* including =
>bsd.own.mk ?
>
>Well, kinda=85 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=3Dno in my makefile, and it caused other MK_ flags to be =
>set, then I=92d have
>to include something to take another run at setting those =
>meta-variables.

Not necessarily.  The stuff in bsd.own.mk like:

.if ${MK_TOOLCHAIN} == "no"
MK_BINUTILS:=   no
MK_CLANG:=      no
MK_GCC:=        no
MK_GDB:=        no
.endif

doesn't need to change, and for more elaborate stuff, simply being able
to include *options.mk more than once may help quite a bit.

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

No, but could do so pretty quickly.
I need to resync projects/bmake and start writing my material for BSDCan
;-) I could look doing this as part of that.

The hardest bit is naming the new makefile ;-)
bsd.options.mk would be an obvious choice - though that conflicts with
ports usage.


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

The ports makefile is much more elaborate but I believe achieves similar
results.   The name conflict could probably be worked around if
bsd.options.mk is considered the best name choice.

--sjg