make WITH[OUT]_* more useful?

[Simon J. Gerraty]

On Tue, 1 Apr 2014 12:57:57 -0600, Warner Losh writes:
>> .if !defined(WITHOUT_CTF) && !defined(NO_CTF)
>> WITH_CTF=3Dyes
>> .endif
>>=20
>> else you get errors during build world.
>
>That's a bug I plan on fixing. 

Agreed, and cool.

>> 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=92ll have to think about this point. It is a good point, but I=92m =
>unsure how
>the proposed changes would fix that. Perhaps you could explain that a =
>bit.

Sure.  For the sake of argument assume I can put something like this in
local.sys.mk:

OPTIONS_DEFAULT_NO+= \
	META_MODE

OPTIONS_DEFAULT_YES+= \
	AUTO_OBJ

.include "options.mk"

.if ${MK_AUTO_OBJ} == "yes"
.include "auto.obj.mk"
.endif
.if ${MK_META_MODE} == "yes"
.include "meta.sys.mk"
.endif

and both

MK_META_MODE={yes,no}
MK_AUTO_OBJ={yes,no}

which are needed during sys.mk can be influenced by user's -DWITH[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.

It "fixes" it by not throwing an error when both WITH_FOO and WITHOUT_FOO
are defined.  Instead, you decree that one wins (eg WITHOUT_FOO
overrides WITH_FOO).

You could also address the conflict by giving preference to command line.
${.MAKEFLAGS:MWITH*} will give you any WITH_* and WITHOUT_* from command
line.  

There might be a rare case where an error is desired on conflict, but
if you can sensibly resolve it that is better.

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

yes.

>I thought that was done bad.obj.mk since it isn't part of the global system.

Traditionally done in bsd.obj.mk - but that requires a separate
invocation of make.

The junos build for example has auto-created objdirs for 10+ years.
The projects/bmake build does the same.
It is a good way to ensure consistent/reliable results and avoid
probelms when users forget to 'make obj'.

When you have to support 2000+ developers you want to be able to
make it hard for them to shoot themselves in the foot.

If making objdirs automatically, you really want to do it early, since
the result influences how make then behaves.

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

An options.mk which does nothing except process the list of
options provided to it, is always safe to include even by sys.mk.
Whereas bsd.own.mk does other stuff which makes it unsuitable to include 
eg. during the early stages of buildworld.
bsd.own.mk can of course set its own list of options and then include
the same options.mk a simple matter of refactoring to allow re-use.

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

Separating the mechanism of option processing from the definition of
options makes re-use easier - see above, sorry I don't know how to make
it clearer.

The other aspects you have at least partially addressed already, by
allowing MK_* to be set independently.
Though:

.if defined(MK_${var})
.if ${.MAKE.LEVEL} == 0
.error MK_${var} can't be set by a user.
.endif

would seem to negate that.  Why can a makefile at level 0 not set MK_*?

The outstanding question is dealing with conflict when both WITH_FOO and
WITHOUT_FOO are defined.

Thanks
--sjg