Subject: Re: Boolean variables (was: Re: improved pkg-vulnerabilities checking)
To: Roland Illig <>
From: Todd Vierling <>
List: tech-pkg
Date: 11/16/2005 13:48:45
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

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 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, 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 <> <> <>