make WITH[OUT]_* more useful?

[Simon J. Gerraty]

>> I'm obviously biased, but I think contrib/bmake/mk/options.mk is close
>> to what is desired - just the mechanism with no policy.
>
>I=92ve created a bsd.srcopt.mk and adjusted bsd.own.mk in a sample patch, s=
>ince
>it sounds like we=92re headed in the right direction. Please take a look at=
> it and
>let me know what you think.

Thanks

>http://people.freebsd.org/~imp/patch-queue/bsd.srcopt.mk
>
>contains the patch and commit message (if I did the queue management right)
>that I=92d like to proffer.

I could be miss-reading this, but it looks like you moved the list of
options to bsd.srcopt.mk ? 
That's not what I was suggesting, though I can see how it might be useful.

I was specifically thinking of a makefile that does not define/know any
options at all.  You set a list of options and include it and
it does the WITH[OUT]_* -> MK_* dance.
Eg. contrib/bmake/mk/options.mk consumes OPTIONS_DEFAULT_* but does not
set even a default list.  If you include it with no options list, it
does nothing - pure mechanism.

Now it might be very useful to extract the list of src options from
bsd.own.mk to something safer to include anytime.
But it is still (I think) useful to separate the options processing
from their definition.

Eg. something like:

bsd.own.mk
	.include <bsd.srcopt[s].mk>
		defines a bunch of options 
		.include <bsd.mkoption[s].mk>
			sets MK_* based on WITH[OUT]_* for the list of
			options provided

or per my comments below about installing, perhaps the list of options
etc might be better in src.options.mk (ie something we don't install?
I just thought of that so take with grain of salt)

Regardless, it might be handy to see the full files, to get a clearer
picture. 

>earlier in this thread. I=92m not tied to what I=92ve posted here, but I wo=
>uld
>like to reach resolution so I can fix some other things in the build without
>much delay.

Sure.

>
>>> Where would the src build pick this up from if =3D
>>> it isn=3D92t installed?
>> =
>
>> src/share/mk should work fine.
>
>OK. I haven=92t added it to the Makefile so it gets installed, and things
>seem to build, but that=92s not a viable way to commit things. Please comme=
>nt
>on what I=92ve done and what you think the right way to proceed might be.
>The easy path is, of course, just installing it :)

Sorry, which file are you talking about? 

FWIW I think all bsd.*.mk should get installed.
but I think it perfectly reasonable to declare that anything matching the
pattern local.* or src.* doesn't get installed.
Hopefully that shouldn't surprise anyone either.

To restate that slightly differently, you can think of these things as a
hierarchy:

bsd.*	mechanism for building stuff (not just /usr/src)
src.*	stuff just for building /usr/src
local.*	local tweaks to all the above

>> Not necessarily.  The stuff in bsd.own.mk like:
>> =
>
>> .if ${MK_TOOLCHAIN} =3D=3D "no"
>> MK_BINUTILS:=3D   no
>> MK_CLANG:=3D      no
>> MK_GCC:=3D        no
>> MK_GDB:=3D        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.
>
>That might be hard, since MK_FOO being set from the first time won=92t

Unless MK_FOO is set on make's commandline, you can override it any time
you like - whether that makes sense or whether it gives people headaches
is another matter.

Most of the current options seem to be more about whether certain
features/apps etc should be built.   Changing the value of such options 
once set doesn't make a lot of sense. eg. no point building libfoo
without support for goop, and then building food with a need for it.

The sorts of knobs more likely to be useful to tweak as we go, are those
that affect how we do building (cf. configuring src), so MK_CTF,
MK_META_MODE, and probably many others we could come up with if the
mechanism were sufficiently flexible and easy to grok.

>> No, but could do so pretty quickly.

Sorry I lied... ;-)

>I opted for a different name to not conflict.

Probably best.

Thanks
--sjg