View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0009123CMakeCMakepublic2009-06-08 23:432010-12-14 18:49
ReporterPaul Oppenheim (Poppy Linden) 
Assigned ToKen Martin 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0009123: Conditionals do not behave as expected from documentation (IF, ENDIF, ELSE)
DescriptionCertain conditional statements that the documentation says should be evaluated as true are not.
Additional InformationNOTE: 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.
TagsNo tags attached.
Attached Files

 Relationships
related to 0010773closedBrad King IF() command behaviour contradicts examples in documentation 

  Notes
(0016669)
Brad King (manager)
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) (reporter)
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 (manager)
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 (developer)
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 (manager)
2010-12-14 18:49

 Closing bugs that have been resolved for more than 3 months without any further updates.

 Issue History
Date Modified Username Field Change
2009-06-08 23:43 Paul Oppenheim (Poppy Linden) New Issue
2009-06-09 11:37 Bill Hoffman Status new => assigned
2009-06-09 11:37 Bill Hoffman Assigned To => Brad King
2009-06-09 11:45 Brad King Note Added: 0016669
2009-06-09 11:45 Brad King Status assigned => closed
2009-06-09 11:45 Brad King Resolution open => no change required
2009-06-09 15:01 Paul Oppenheim (Poppy Linden) Note Added: 0016674
2009-06-09 15:01 Paul Oppenheim (Poppy Linden) Status closed => feedback
2009-06-09 15:01 Paul Oppenheim (Poppy Linden) Resolution no change required => reopened
2009-06-09 15:05 Brad King Status feedback => assigned
2009-06-09 15:05 Brad King Assigned To Brad King => Ken Martin
2009-06-09 15:07 Brad King Note Added: 0016675
2009-06-15 12:51 Ken Martin Note Added: 0016723
2009-06-15 12:51 Ken Martin Status assigned => resolved
2009-06-15 12:51 Ken Martin Resolution reopened => fixed
2010-12-14 18:49 David Cole Note Added: 0024097
2010-12-14 18:49 David Cole Status resolved => closed
2011-01-14 17:35 Brad King Relationship added related to 0010773

Copyright © 2000 - 2018 MantisBT Team