Better way to do conditional inclusion in make

[Warner Losh]

> On Feb 5, 2015, at 5:41 PM, Julian Elischer <julian at freebsd.org> wrote:
> 
> On 2/6/15 1:56 AM, Warner Losh wrote:
>> Greetings,
>> 
>> I’ve started a pass through the tree to cleanup how we do conditional inclusion in our build system.
>> 
>> https://reviews.freebsd.org/D1781
>> 
>> It moves away from
>> 
>> .if ${MK_foo} != “no”
>> FILES+= files
>> .endif
>> 
>> and
>> 
>> SUBDIRS= … ${_foo} …
>> ...
>> .if ${MK_foo} != “no”
>> _foo+= foo
>> .endif
>> 
>> and instead more directly assigns things. We know that MK_foo is always going to be yes or no
>> for build options. We can leverage that fact, and the fact that bmake is so much better at variable
>> expansion than fmake was (especially in the early days) to instead move to something like:
>> 
>> FILES=list of unconditional files here ${FILES.yes}
>> FILES.${MK_foo}+=foo bar biz
>> FILES.${MK_baz}+=baz bing boo
>> 
>> which eliminates a whole lot of needless .if / .endif lines, lots of extra blank lines, etc.
>> 
>> Comments?
> 
> how does it cope with the case where a single file is dependent on either of two options.
> (we have this in our tree.. not sure if it occurs in the FreeBSD tree.)
> file could occur in both lists or twice in one list..

We have this in our tree a fair amount. power, for example, is enabled with either MK_ACPI or
MK_APM. When it is either/or, just list it for both.

FILES.${MK_APCI}+= acpiconf powerd
FILES.${MK_APM}+= powerd

The FILES:=${FILES:O:u} at the end sorts everything and removes the duplicates.

Warner