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

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Reply via email to