On Wed, 16 Nov 2005, Roland Illig wrote:

> I see that this can lead to confusion. To resolve this, the way I prefer most
> would be not to use
>
>     .if defined(VAR)
>
> when checking for boolean variables, but to use
>
>     .if defined(VAR) && !empty(VAR:M[Yy][Ee][Ss])

As I've noted once before:  This has a runtime impact in that such variables
are not usable in ${FOO:D...} constructs.  For instance, see
mk/platform/Interix.mk:

CONFIGURE_ENV+=		${GNU_CONFIGURE:Dac_cv_header_poll_h=no ac_cv_func_poll=no}
...
CONFIGURE_ENV+=		${GNU_CONFIGURE:Dac_cv_func_hstrerror=yes}

The reason I chose these constructs is because they work regardless of when
bsd.prefs.mk is pulled in -- rather than depending on GNU_CONFIGURE being
set *before* it is included.  There are a couple of packages that set
GNU_CONFIGURE after including bsd.prefs.mk, so this was necessary.

Remember that variables are expanded on demand, whereas .if directives and
:= assignments are expanded at parse time.  You have to be *very* careful
about ordering the more you use .if and := operations.

For these and similar reasons, I strongly *dislike* the idea of moving any
existing variables using a defined-check to the :M[Yy][Ee][Ss] form.  (In
fact, there are a few variables for which going the other way -- they are
currently yes/no, but could be changed to defined/undefined -- would be
preferable to allow constructs such as the above to work.)

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>