Use better make construct for conditional variables

[imp]

Summary

Leverage the fact that MK_foo are always defined to either yes or no
and bmake's robustness of variable expansion to simplify the ifdef
soup these files are growing. Use

FILES.${MK_foo}+= files

in preference to

.if ${MK_foo} != "no"
FILES+= files
.endif

separated by blank lines to save 3 lines per option we test. Include
${FILES.yes} at the end of FILES to pick these up. Assume the file
list for each option is small and stable so place it on one line. Stop
using the traditional _file = file construct as well to make things
uniform.

[ngie]

This would be confusing to end-users that specify MK_foo != "no" || "yes":

29 .for var in ${__DEFAULT_YES_OPTIONS}
30 .if !defined(MK_${var})

In particular code around the tree that says != "no" implies that "yes" is the default (except OptionalObsoleteFiles.inc and a handful of other places that explicitly test for "no"). With this change, the default is flip-flopped, i.e. "no" is implied unless you explicitly say "yes" for a given option.

[ngie]

I really like the simplicity of the concept.

1. We should have a series of recipes/examples and documentation on when to use which format so it won't confuse people too much (I wish I wasn't a few of the token "build-aware" people at Isilon).
2. We need to have a quick plan/agreement for when to MFC these changes, or how to handle MFCs (there's still a lot in ^/projects/building-blocks that I need to take care of before I can kill off the branch).
3. We might want to add some "strictness" to bsd.*opt.mk to ensure that people don't accidentally footshoot themselves like I described in the previous comment.

[emaste]

Could you put a version of the summary / commit message text as a comment in the file? It seems straightforward now but I can imagine coming back in five or ten years and having to spelunk the commit history to figure out what's going on.

[imp]

Since I plan on doing this to a bunch of files in the tree, I think the comment belongs in style.Makefile.9 since it would be replicated in a bunch of places.

[imp]

ngie: the options are literally only ever yes or no. No other values are valid.

[ngie]

etc/rc.d/Makefile

129

The negative side about this approach, is that it will overflow 80 columns quicker and could result in a greater number of conflicts longterm if local modifications are made to this file. Should this space multiple lines, e.g.

FILES.${MK_AUTOFS}+= \
    automount \
    automountd \
    autounmountd \

etc?

288–289

FWIW, I'm kind of surprised this doesn't just use SCRIPTS...

[emaste]

I believe most (all?) of this has been done?

[imp]

Whatever's been committed in this area is all the work I'm doing