make WITH[OUT]_* more useful?

[Warner Losh]

On Apr 17, 2014, at 12:34 AM, Simon J. Gerraty <sjg at juniper.net> wrote:

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

This was step one: separate out the options processing from the bsd.own.mk stuff.
Having a few lines that are generic would be nice to include. I’d like to go ahead and
commit step 1, even if we refine things a bit later to keep the change sets manageable
and under control… Is that reasonable? It will help other areas and we don’t need to
do much more than settle on filenames. :)

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

Yea, that was the notion of the next step.

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

Yea, this is just the first step.

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

Yea, I have some concerns about going that far. See below.

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

My bsd.srcopts.mk was what I was talking about here needing to be added to share/mk/Makefile.

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

IF we can achieve that separation, then great.

> 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

Yes, as long as the MK_FOO variables that are really src building stuff don’t
infect the bsd.foo.mk files, this could work out. Keeping the infection rate down
might be hard, but not impossible to manage.

Would we do a wholesale change of bsd.foo.mk to src.foo.mk for all the Makefiles
in the tree if we went down this path? Or would the src.XXX stuff just be for the
orchestration we do between the different directories and such and we’d continue
to build them the way we always have?

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

Yea. That does make a certain amount of sense.

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

Yea, I’m not too hung up on the edge cases, but want to make sure that we know
the limitations going into this.

Warner

>>> No, but could do so pretty quickly.
> 
> Sorry I lied... ;-)
> 
>> I opted for a different name to not conflict.
> 
> Probably best.
> 
> Thanks
> --sjg
>