[cmake-developers] if (FOO == BAR) ...

Matthew Woehlke matthew.woehlke at kitware.com
Wed Mar 20 19:08:49 EDT 2013


On 2013-03-20 17:42, Alexander Neundorf wrote:
> On Wednesday 20 March 2013, Matthew Woehlke wrote:
>> On 2013-03-20 17:10, David Cole wrote:
>>> Are you proposing that == behaves as STREQUAL, or as EQUAL?
>>
>> What's the difference?
>>
>> Okay, for <, >, there is an obvious answer, but for ==, I am trying and
>> failing to think of a situation where treating the arguments as numbers
>> would give a different result vs. treating them as strings.
>
> E.g. "0" vs. "0.0"

Is "0.0" a floating-point number or a version string? In the context of 
CMake, I would have rather expected it to be the latter. (Does CMake 
even understand floating point?) If '==' assumes numbers, how do I tell 
it I really meant a version string?

>>> given that I already know how these things work with if(VARIABLE
>>> constructs, I would expect that same thing from this new syntax.
>>> i.e. if(VAR == 5) works just like if(${VAR} == 5)
>>
>> This I think I would expect also.
>
> Oh, really ?
> Docs would say something like " == compares the strings for equality"
>
> if(VAR == 5)
> would be the same as
> if("VAR" == "5")
> If you want to check the value, dereference it:
> if("${VAR}" == "5")

I think most programmers expect 'if(VAR == 5)' to dereference 'VAR'... 
otherwise the statement is silly. So...

>> What I would expect to be different
>> from STREQUAL is that 'if("${var}" ==' is NOT the same as 'if(${var} =='.
>
> You'd expect the quotes to make a difference ?

...yes. IMO it's not so much that CMake's implicit dereferencing is 
inherently broken, as that something you would expect to prevent it 
(quoting string literals) does not do so.

-- 
Matthew




More information about the cmake-developers mailing list