Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 06 Feb 2015 08:41:40 +0800
From:      Julian Elischer <julian@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <arch@FreeBSD.org>
Subject:   Re: Better way to do conditional inclusion in make
Message-ID:  <54D40DC4.9070907@freebsd.org>
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 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..

> Warner
>
>
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
>
>
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D40DC4.9070907>