[CMake] too many kinds of FALSE

[Brandon Van Every]

On Dec 16, 2007 11:57 AM, David Cole <david.cole at kitware.com> wrote:
> 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.

What's an example in the CMake source pool where they're actually used
for something?  Or VTK or ITK?  I've never had a reason to use "n" or
"N".  Is this something from the earliest days of CMake that looked
like a good idea at the time, but that nobody really used?

> If you have a suggestion on how to improve things without breaking backwards
> compatibility, I'm sure we'd all love to hear it.

Sure.  A function to turn off the interpretation of various kinds of
FALSE.   That's generally how you'd handle any kind of backwards
compatibility problem.  Give the user the ability to turn off legacy
behavior.

At the same time, one could provide type safe constructs, like boolean
variables, so that current CMake users adopt better practices.  Over
time, you'll have a quorum of people turning off the legacy stuff.
Then perhaps the legacy behavior can be retired.

Another way to prod people into retiring legacy constructs, is to
issue warnings during execution about the existence of those
constructs.  Or if that's too draconian, provide an option to issue
such warnings.

> But otherwise, I would
> strongly suggest using STREQUAL instead of IF(VARIABLE) with any regex
> result.
>
> ...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.

I think you mean to recommend
IF(thematch STREQUAL "")

I may do that from now on.  But there's a "gotcha" waiting with that
style of coding: a null variable, and a variable set to an empty
string, are not equivalent.

SET(void)
SET(empty "")
IF(void STREQUAL empty)
  MESSAGE("void and empty are equivalent")
ELSE(void STREQUAL empty)
  MESSAGE("void and empty are different")
ENDIF(void STREQUAL empty)
set(myvar)
if(myvar STREQUAL "")
  message("It would be prudent to initialize myvar, or Bad Things will happen.")
else(myvar STREQUAL "")
  message("Gosh I'm sure glad I initialized myvar, nothing bad will happen!")
endif(myvar STREQUAL "")

C:\devel\src\cbugs\strequal>cmake -P strequal.cmake
void and empty are different
Gosh I'm sure glad I initialized myvar, nothing bad will happen!

I think it cost me 1/2 a workday to figure that one out.  Having to
remember these subtleties is really bad.  Especially since they're not
documented; you can really only learn them through the school of hard
knocks.  I think CMake needs a type safety injection somewhere.


Cheers,
Brandon Van Every