make WITH[OUT]_* more useful?

[Warner Losh]

Hi Simon,

On Apr 9, 2014, at 9:46 PM, Simon J. Gerraty <sjg at juniper.net> wrote:

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

I’ve created a bsd.srcopt.mk and adjusted bsd.own.mk in a sample patch, since
it sounds like we’re headed in the right direction. Please take a look at it and
let me know what you think.

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’d like to proffer.

If we can make this somehow more generic, I’d be game, but we have some
fairly ugly interdependencies that may complicate a clean, simple solution.

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

Yea, we can work out the policy mechanism for this. I was kinda hoping
to be able to use this tool to fix the NO_CTF issue that we talked about
earlier in this thread. I’m not tied to what I’ve posted here, but I would
like to reach resolution so I can fix some other things in the build without
much delay.

>> Where would the src build pick this up from if =
>> it isn=92t installed?
> 
> src/share/mk should work fine.

OK. I haven’t added it to the Makefile so it gets installed, and things
seem to build, but that’s not a viable way to commit things. Please comment
on what I’ve done and what you think the right way to proceed might be.
The easy path is, of course, just installing it :)

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

That might be hard, since MK_FOO being set from the first time won’t
allow us to override them the second or further time. I opted for a guard
target in my rendition, but now that I think about it, I’m not so sure that’s
needed and multiple include would allow us to remove the current
restriction that you can’t toggle MK_META from “no” to “yes” after
we’ve included the option.mk file.

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

Yea, I chose bsd.srcopt.mk for my doodles.

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

I opted for a different name to not conflict.

Warner