View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010773CMakeCMakepublic2010-05-28 13:012011-01-31 16:01
ReporterModestas Vainius 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformamd64OSDebian GNU/LinuxOS Versionsid
Product VersionCMake-2-8 
Target VersionCMake 2.8.4Fixed in VersionCMake 2.8.4 
Summary0010773: IF() command behaviour contradicts examples in documentation
DescriptionExerpt from `cmake --help-command if`
---------------------------------------------------

 The convenience feature that sometimes
  throws new authors is how CMake handles values that do not match the
  true or false list. Those values are treated as variables and are
 dereferenced even though they do not have the required ${} syntax.
 This means that if you write

         if (boobah)

 CMake will treat it as if you wrote

         if (${boobah})

 likewise if you write

         if (fubar AND sol)

 CMake will conveniently treat it as

         if ("${fubar}" AND "${sol}")

 The later is really the correct way to write it, but the former will
 work as well. Only some operations in the if statement have this
 special handling of arguments.
----------------------------------------

Then why almost straight copy&paste code below produces different results for each pair (see Testcase: lines) when variables are set to a string value? And why is "why_is_this_string_false" constant false? cmake appears to treat "why_is_this_string_false" as variable which is really unintuitive but maybe somewhat deductable from documentation.

So there is either a bug in cmake or in its documentation.
Steps To Reproduceproject(foo)
cmake_minimum_required(VERSION 2.6)

set(boobah "str")
set(fubar "str")
set(sol "str")

if (boobah)
    MESSAGE(STATUS "Testcase: boobah without brackets")
endif(boobah)

if (${boobah})
    MESSAGE(STATUS "Testcase: boobah with brackets")
endif (${boobah})

if (fubar AND sol)
    MESSAGE(STATUS "Testcase: fubar sol without brackets")
endif (fubar AND sol)

if ("${fubar}" AND "${sol}")
    MESSAGE(STATUS "Testcase: fubar sol with brackets")
endif ("${fubar}" AND "${sol}")

if ("why_is_this_string_false")
    MESSAGE(STATUS "Testcase: no, why_is_this_string_false is NOT false")
endif ("why_is_this_string_false")
Additional Information$ rm CMakeCache.txt -f && cmake .
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /mnt/sda2/usr/bin/gcc
-- Check for working C compiler: /mnt/sda2/usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /mnt/sda2/usr/bin/c++
-- Check for working CXX compiler: /mnt/sda2/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Testcase: boobah without brackets
-- Testcase: fubar sol without brackets
-- Configuring done
-- Generating done
-- Build files have been written to: /home/modax/test
TagsNo tags attached.
Attached Files

 Relationships
related to 0009123closedKen Martin Conditionals do not behave as expected from documentation (IF, ENDIF, ELSE) 
has duplicate 0011701closedBrad King Check condition evaluation for a passed variable 

  Notes
(0020870)
Rolf Eike Beer (developer)
2010-05-31 02:15

 Please add your CMakeLists.txt.
(0020871)
Modestas Vainius (reporter)
2010-05-31 03:21

 It's in "Steps to Reproduce" section.
(0020872)
Rolf Eike Beer (developer)
2010-05-31 07:33

 Ah, sorry, that one is not shown by default ;)
(0024697)
Brad King (manager)
2011-01-14 17:33

 Ugh, the phrase "CMake will treat it as if you wrote" is very misleading and needs to be corrected. The logic implemented by the command predates the ${} evaluation syntax (we're talking *ancient* history here) so it does some magic evaluation. This portion of the documentation was added by this commit:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a73071ca#patch2 [^]

in part to address issue 0009123. That commit was a bit buggy itself so another commit was made to fix it:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cb185d93#patch2 [^]

The latter commit clearly and correctly specifies the behavior in the uppor portion of the documentation but did not change the bad phrasing added by the former commit.
(0024698)
Brad King (manager)
2011-01-14 18:30

 This should do it:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4e14e85 [^]

 Issue History
Date Modified Username Field Change
2010-05-28 13:01 Modestas Vainius New Issue
2010-05-31 02:15 Rolf Eike Beer Note Added: 0020870
2010-05-31 03:21 Modestas Vainius Note Added: 0020871
2010-05-31 07:33 Rolf Eike Beer Note Added: 0020872
2011-01-14 17:20 Brad King Relationship added has duplicate 0011701
2011-01-14 17:22 Brad King Assigned To => Brad King
2011-01-14 17:22 Brad King Status new => assigned
2011-01-14 17:33 Brad King Note Added: 0024697
2011-01-14 17:35 Brad King Relationship added related to 0009123
2011-01-14 18:30 Brad King Note Added: 0024698
2011-01-14 18:30 Brad King Status assigned => closed
2011-01-14 18:30 Brad King Resolution open => fixed
2011-01-31 16:01 David Cole Fixed in Version => CMake 2.8.4
2011-01-31 16:01 David Cole Target Version => CMake 2.8.4

Copyright © 2000 - 2018 MantisBT Team