[CMake] BOOL type

[James Bigler]

On Dec 18, 2007, at 7:48 AM, Bill Hoffman wrote:

> James Bigler wrote:
>
>> I also agree that trying to maintain backwards compatibility to  
>> the detriment of the future can become a hinderance.  I just had a  
>> collegue who was extreemly frustrated for several hours with why  
>> his build didn't work, only to discover that he should have been  
>> using ADD_SUBDIRECTORIES instead of SUBDIRS.  There was no warning  
>> from CMake stating that he shouldn't be using it (I would argue  
>> that CMake should warn about the use of SUBDIRS).
> That would be lots of warnings!  SUBDIRS was the only way to do  
> things for a long time.  CMake itself still uses them so it can be  
> bootstrapped with older versions of CMake.  SUBDIRS still works, it  
> just works different.  The behavior of both are documented.

"The ADD_SUBDIRECTORY command should be used instead of SUBDIRS  
although SUBDIRS will still work."

There isn't a mention in the docs that SUBDIRS behaves differently to  
ADD_SUBDIRECTORIES in the man page, just that it should work.

Part of the problem with my collegue is that he was copying code from  
another part of the build system.  He was new to cmake and hadn't  
read the whole man page.  He just assumed the one way he found to  
traverse subdirectories was the one to use.  It's really confusing to  
have two ways to do basically the same thing with only subtle  
differences.

I guess my argument is that changing syntax shouldn't be shied away  
from, but it would be nice to have a way to flush out old code.

> Aside from the backwards compatibility issue, this cmake code  
> should work, but it produces a FATAL_ERROR:
>> SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)
>> SET(A TRUE)
>> SET(B FALSE)
>> IF(A EQUAL B)
>>   MESSAGE(FATAL_ERROR "${A} shouldn't equal ${B}")
>> ELSE()
>>   MESSAGE("${A} should equal ${B}")
>> ENDIF()
>> SET(B 1)
>> IF(A EQUAL B)
>>   MESSAGE("${A} should equal ${B}")
>> ELSE()
>>   MESSAGE(FATAL_ERROR "${A} shouldn't equal ${B}")
>> ENDIF()
>
> Why should TRUE EQUAL 1?
>
> From the docs of IF:
>
>   IF(variable LESS number)
>   IF(string LESS number)
>   IF(variable GREATER number)
>   IF(string GREATER number)
>   IF(variable EQUAL number)
>   IF(string EQUAL number)
>
> True if the given string or variable's value is a valid number and  
> the inequality or equality is true.
>
> TRUE is not a valid number, EQUAL only works on numbers.

OK, then how would you write the equality to be agnostic to the type  
of conditional?

James