MantisBT - CMake
View Issue Details
0009123CMakeCMakepublic2009-06-08 23:432010-12-14 18:49
Paul Oppenheim (Poppy Linden) 
Ken Martin 
normalmajoralways
closedfixed 
CMake-2-6 
 
0009123: Conditionals do not behave as expected from documentation (IF, ENDIF, ELSE)
Certain conditional statements that the documentation says should be evaluated as true are not.
NOTE: I could just be "doin it wrong" because this seems too big to be unnoticed.

http://cmake.org/cmake/help/cmake2.6docs.html#command:if [^]

"""
  if(variable)

True if the variable's value is not empty, 0, N, NO, OFF, FALSE, NOTFOUND, or <variable>-NOTFOUND.
"""

So these should evaluate to true, but do not (assume SET(parent sometarget) )
if (parent)
if (TRUE)
if (DEFINED parent)

This works:
if (1)

Not sure if this is relevant, but I'm talking about code inside a macro.

Here is the conditional I'm talking about (modified for the several examples listed)
http://svn.secondlife.com/trac/linden/browser/trunk/indra/cmake/LLAddBuildTest.cmake?rev=2022 [^]

See Line 114 - that won't work as written (it's an improper dereference) but should work as if(parent) but doesn't. If I get rid of the conditional the dep is setup correctly.
No tags attached.
related to 0010773closed Brad King IF() command behaviour contradicts examples in documentation 
Issue History
2009-06-08 23:43Paul Oppenheim (Poppy Linden)New Issue
2009-06-09 11:37Bill HoffmanStatusnew => assigned
2009-06-09 11:37Bill HoffmanAssigned To => Brad King
2009-06-09 11:45Brad KingNote Added: 0016669
2009-06-09 11:45Brad KingStatusassigned => closed
2009-06-09 11:45Brad KingResolutionopen => no change required
2009-06-09 15:01Paul Oppenheim (Poppy Linden)Note Added: 0016674
2009-06-09 15:01Paul Oppenheim (Poppy Linden)Statusclosed => feedback
2009-06-09 15:01Paul Oppenheim (Poppy Linden)Resolutionno change required => reopened
2009-06-09 15:05Brad KingStatusfeedback => assigned
2009-06-09 15:05Brad KingAssigned ToBrad King => Ken Martin
2009-06-09 15:07Brad KingNote Added: 0016675
2009-06-15 12:51Ken MartinNote Added: 0016723
2009-06-15 12:51Ken MartinStatusassigned => resolved
2009-06-15 12:51Ken MartinResolutionreopened => fixed
2010-12-14 18:49David ColeNote Added: 0024097
2010-12-14 18:49David ColeStatusresolved => closed
2011-01-14 17:35Brad KingRelationship addedrelated to 0010773

Notes
(0016669)
Brad King   
2009-06-09 11:45   
The documentation of macro():

  http://www.cmake.org/cmake/help/cmake2.6docs.html#command:macro [^]

states that its arguments are not real variables. They are placeholders such that "${arg}" is replaced before evaluation. The if() command says it works with variables. As far as macro() is concerned, the argument "parent" is just a string and is not replaced.
(0016674)
Paul Oppenheim (Poppy Linden)   
2009-06-09 15:01   
Right, but if that's the case, then if(1) shouldn't evaluate to true. So which behavior is correct? Consts are evaluated or not? Only numeric constants? Only numeric consts on a monday?
(0016675)
Brad King   
2009-06-09 15:07   
Ken, can you document in if() how it treats constants, please?

Poppy, this is left from VERY early days in CMake when there was no variable dereference syntax (${var}). The if command magically expands variable that are defined when they are specified by name.
(0016723)
Ken Martin   
2009-06-15 12:51   
Updated the logic of the if command so that variables passed in behave more consistently. Specifically statements like "if (foo)" and "if (${foo})" will resolve to the same result, in the past they did not always do so. Added policy CMP0012 for this as in some very rare case it could change behavior.

Also updated the documentation on the if statement to be a bit clearer on how it treats arguments and what constants work. Now for example "if (true)" will evaluate to true.

In the original example above "if (parent)" and "if (DEFINED parent)" would still evaluate to false as parent is a macro definition not a variable. The same two statement inside of a function (as opposed to a macro) would work fine.
(0024097)
David Cole   
2010-12-14 18:49   
Closing bugs that have been resolved for more than 3 months without any further updates.