CMake defines "FALSE" as a string that's empty, 0, N, NO, OFF, FALSE,
NOTFOUND, or <variable>-NOTFOUND. I just realized that my regexes are
not safe with respect to capturing the letter "n".
set(sillystring "The rain in spain")
string(REGEX MATCH
".$"
thematch "${sillystring}")
if(thematch)
message("regex works")
else(thematch)
message("regex doesn't work")
endif(thematch)
C:\devel\src\cbugs\trueorfalse>cmake -P trueorfalse.cmake
n is false
regex doesn't work
What's so great about "n" and "no" ? 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?
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@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
