Better way to do conditional inclusion in make

[Warner Losh]

> On Feb 5, 2015, at 6:39 PM, NGie Cooper <yaneurabeya at gmail.com> wrote:
> 
> On Thu, Feb 5, 2015 at 5:26 PM, Simon J. Gerraty <sjg at juniper.net> wrote:
>> NGie Cooper <yaneurabeya at gmail.com> wrote:
>>>> 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..
>>> 
>>> This is a good, valid point. I think that Warner's proposal will fix
>>> the simple case (using one knob), but not the more complex case.
>> 
>> FILES:= ${FILES:O:u}
>> 
>> should cover that case.
> 
> Yes, but not this:
> 
> .if ${MK_BAR} != "no" && ${MK_FOO} != "no"
> FILES+= a_lot_of_bar_in_my_foo
> .endif

There’s very few cases of this in the tree, so who cares :) You just add
the old school .if.

>>> What concerns me about the short description of the implementation,
>>> (and something that I'm going to add to the phabricator review) is
>>> that this will:
>>> 
>>> 1. Break using FILESGROUPS
>> 
>> Why?
> 
> The same reason why bsd.progs.mk didn't work with bsd.prog.mk on
> FreeBSD out of the box originally -- defaults:

bsd.progs.mk is evil and should die :) I tried to leave this line out, but couldn’t :)

> 10 FILESGROUPS?=   FILES
> 11
> 12 .for group in ${FILESGROUPS}
> 13 buildfiles: ${${group}}
> 14 .endfor
> 15
> 
> Warner's change (based on what I understand, again I haven't looked at
> the review yet…)

You should, it would answer why this isn’t an issue.

> would require setting FILESGROUPS explicitly. So if
> you had a Makefile snippet that defines the non-default FILESGROUPS
> already, it will break that usecase.

Why? I don’t set why it matters at all. This wouldn’t affect the FILES variable
expansion in line 13 at all. How would it break?

>>> 2. Requires creating snippets for dealing with magic in bsd.*.mk (I
>>> wouldn't want this magic going into the general purpose snippets
>>> because it would probably break backwards compatibility).
>> 
>> Not necessarily eg. if you clean/simplify the list after building it.
> 
> I'll delay my reply on this because my other replies might change my question.

OK.

Warner