Date: Thu, 5 Feb 2015 10:09:46 -0800 From: Justin Hibbits <jhibbits@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Better way to do conditional inclusion in make Message-ID: <CAHSQbTAYZi3RkbA-krMos2wH7KPwEbhD=_iYYUHLPxibnh=5GA@mail.gmail.com> In-Reply-To: <39C20BA1-E6B1-4DAE-95BB-8011A0A64D54@bsdimp.com> References: <39C20BA1-E6B1-4DAE-95BB-8011A0A64D54@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 5, 2015 at 9:56 AM, Warner Losh <imp@bsdimp.com> 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? > > Warner I like it. It makes it easier to see at a glance what options are available, and how the files are guarded. - Justin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHSQbTAYZi3RkbA-krMos2wH7KPwEbhD=_iYYUHLPxibnh=5GA>