Date: Thu, 5 Feb 2015 15:33:52 -0800 From: NGie Cooper <yaneurabeya@gmail.com> To: Dimitry Andric <dim@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Better way to do conditional inclusion in make Message-ID: <CAGHfRMCeLY2rUnVCqs2frWkcOfLbp99o%2BVyornd88j7hWuGZ0w@mail.gmail.com> In-Reply-To: <B72A818B-A8ED-45C3-998E-D179F6B9F71D@FreeBSD.org> References: <39C20BA1-E6B1-4DAE-95BB-8011A0A64D54@bsdimp.com> <B72A818B-A8ED-45C3-998E-D179F6B9F71D@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 5, 2015 at 1:32 PM, Dimitry Andric <dim@freebsd.org> wrote: > On 05 Feb 2015, at 18:56, Warner Losh <imp@bsdimp.com> wrote: >> >> 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? > > One disadvantage is that you then cannot intersperse MK_foo files or > subdirs in between unconditional ones, and keep a certain order, e.g. > like: > > FILES+= a b c > .if ${MK_foo} != "no" > FILES+= d e f > .endif > FILES+= g h i > > Of course, this is only important for a few particular places, most of > the tree should not care too much about the order in which subdirs or > files are built. Depending on implicit ordering like that is brittle and I'd rather not enable this kind of pattern...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMCeLY2rUnVCqs2frWkcOfLbp99o%2BVyornd88j7hWuGZ0w>