[CMake] too many kinds of FALSE

[David Cole]

On 12/16/07, Brandon Van Every <bvanevery at gmail.com> wrote:
>
> What's so great about "n" and "no" ?


Nobody has claimed that they are great...

I've never used them.  Do we
> really need to be polluting the interpretation of strings with these
> values?  What current or legacy code is using them heavily?


We cannot know. We can only assume that somebody somewhere is probably using
them since they are part of how CMake currently works.

If you have a suggestion on how to improve things without breaking backwards
compatibility, I'm sure we'd all love to hear it. But otherwise, I would
strongly suggest using STREQUAL instead of IF(VARIABLE) with any regex
result.

Instead of...
IF(thematch)

...you should use
IF(NOT "${thematch}" STREQUAL "0")

I know it's not as pretty or elegant as the former, but it works always
regardless of the contents of thematch. In this particular case, it looks
like you are trying to test for 0 or non-0 as the last character of the
input and are mad that "n" is the same as "0" in a cmake variable-based IF
statement. Is that correct?


HTH,
David


ON and OFF are used in the Options, but why can't these just be TRUE
> and FALSE, so that there's less variety of how we specify TRUE and
> FALSE?  Alternately, how about defining a boolean storage type to hold
> options?
>
> How about a numerical storage type, so that 0 and "0" aren't the same
> thing?  And so that we don't have to type MATH(EXPR var "${var} - 1"),
> we could just type var = var - 1.  The problem with assuming that "0"
> means FALSE, is it assumes I got my "0" by counting with a MATH
> expression.  What if I got my "0" by matching with a regex, like a
> digit of a library version?
>
> "-NOTFOUND" doesn't trouble me so much, as it's unlikely to be
> accidentally matched in a regex.
>
>
> Cheers,
> Brandon Van Every
> _______________________________________________
> CMake mailing list
> CMake at cmake.org
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20071216/4aae13a6/attachment.htm