make WITH[OUT]_* more useful?

[Warner Losh]

On Apr 1, 2014, at 10:29 AM, Simon J. Gerraty <sjg at juniper.net> wrote:

> 
> On Tue, 1 Apr 2014 08:22:18 -0600, Warner Losh writes:
>>>> re-implement the WITH_* vs WITHOUT_* logic repeatedly.
>> 
>> Where, exactly, do we do this? In my recent gripping I=92ve found almost
> 
> I hit this just about every possible way while trying to support
> WITH[OUT]_BMAKE 
> in such a way that people could build head on 9 etc.
> Incluing in-tree bsd.own.mk so MK_BMAKE would get set - broke building
> on 9 IIRC.
> 
> Being able to simply do MK_BMAKE?= {yes,no} would have been best solution.
> 
> Also I normally want to built WITH_CTF, but of course you cannot simply
> put that in make.conf you have to 
> 
> .if !defined(WITHOUT_CTF) && !defined(NO_CTF)
> WITH_CTF=yes
> .endif
> 
> else you get errors during build world.

That’s a bug I plan on fixing. But an interesting one because much of the extra
garbage there is due to the duality in the build system where we bogusly (IMHO)
set WITHOUT_CTF on the make command line, plus have an extra special
NO_CTF option which does the same sort of thing.

Bugs in bmake prevent the simple undefining of certain symbols on the command
line, which makes at least part of the above construct necessary.

>>>> It is also generally bad to include bsd.own.mk from sys.mk, which means
>>>> any knobs you need early must re-implement the WITH_* vs WITHOUT_* logic
>>>> repeatedly.
>> 
>> Again, I find no evidence of this in the tree, can you cite specific exampl=
> 
> It isn't done anymore (was certainly done back in 2.x, don't recall when
> it was removed), which is good, but means that sys.mk cannot use
> any MK_* that the user can influence via WITH[OUT]_*.  
> That's  not so much a problem for existing options, but makes it
> impractical to leverage the mechanism for things you might want to set
> during sys.mk - like whether to use meta mode or auto objdir creation.

I’ll have to think about this point. It is a good point, but I’m unsure how
the proposed changes would fix that. Perhaps you could explain that a bit.

>> I mostly hate this. Specifically, I don=92t like the DOMINANT bits. They ar=
>> e unnecessary.
> 
> I mostly agree - I find it quite reasonable to simply allow WITHOUT to win.
> DOMINANT_* is just an "out" in case there's some future case I haven't
> thought of.   The default behavior remains that WITHOUT wins.
> 
>> WITH/WITHOUT is a user-only knob. 
> 
> Agreed, but the implementation renders it user unfriendly.
> If everywhere I want to set a default (eg make.conf) I have to do a
> dance like
> 
> .if !defined(WITHOUT_CTF) && !defined(NO_CTF)
> WITH_CTF=yes
> .endif
> 
> it isn't exactly helping me as much as it could.
> If the build stops using WITH/WITHOUT internally that probably helps.

Yea, that’s just a bug… We have severe options like this, but CTF is one
of the more annoying.

>> The build system should never use it, but always
>> set MK_* directly. 
> 
> Agreed - that would be most useful and is one of the main changes in my
> version.

Already in the tree.

>> I recently fixed it so the build system can start doing =
>> that. This solves
>> the WITH and WITHOUT problem internally.
> 
> That's good - being able to set MK_* directly without causing error
> does address the issue for the build itself.
> 
> Alone though it doesn't necessarily make life any better for users
> who (per my example above) want to set defaults like
> WITH_CTF= in make.conf but occasionally override them.  Unless they too
> are supposed to set MK_* directly but then what is the point of
> WITH[OUT]_* ?

Setting defaults in make.conf, and then overriding them is tough because
bmake doesn't have a tracking system to know where in the food-chain
different variables are set. However, this is also a good point, but I
must be being dense to see how your proposal would fix this.

>> I'm still not sure I see the big win.
> 
> I have a number of knobs to be set during sys.mk
> AUTO_OBJ automatically create objdirs
> META_MODE use meta mode

objdirs set in sys.mk? I thought that was done bad.obj.mk since it isn’t
part of the global system.

META_MODE might belong there.

> setting MK_* is fine, but it is nice if you allow the user to interact
> using WITH[OUT]_*, and for that it is best if sys.mk can safely include
> something like options.mk

Not sure how creating a new file solves the bsd.own.mk problem, apart
perhaps from some name space pollution differences.

> Of course the user can learn to MK_AUTO_OBJ=no but that simply devalues
> WITH[OUT]_* 
> 
> It is a neat mechanism, that with some minor tweaks could be much more
> useful.

It is neat and simple now, but the WITH/WITHOUT stuff was neat and simple
when we started and it has devolved as people have hacked on it without
proper care.

> Baptiste writes:
>>> I would be interested in having your opinion on what we did for ports.
> 
> It is a bit more elaborate (422 lines vs 59 in options.mk)
> that's probably a necessity for ports, but not so sure about inclusion
> by sys.mk

Yea, back to the point I don’t understand: how is your new file going to be
materially different than the current mechanism. I’m OK with change, but I
need to understand how the change is going to make things better.

Warner