MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011410CMakeCMakepublic2010-11-05 12:382016-06-10 14:31
ReporterMarcel Loose 
Assigned ToBen Boeckel 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 2.8.3 
Target VersionCMake 2.8.4Fixed in Version 
Summary0011410: Result of IF(<LIST>) is inconsistent
DescriptionThis is a spin-off of issue 0009043 (see towards the bottom of the comments).

IF(<LIST>) produces inconsistent results. See the output of CMake when run on the following CMakeLists.txt file:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(List NONE)
set(a "NOTFOUND")
set(b "blub-NOTFOUND")
set(c "bar;blub-NOTFOUND")
set(d "blub-NOTFOUND;bar")
foreach(x a b c d)
  if("${x}")
    set(val TRUE)
  else()
    set(val FALSE)
  endif()
  message(STATUS "${x} -> ${val}")
endforeach()

$ cmake ..
-- a -> FALSE
-- b -> FALSE
-- c -> FALSE
-- d -> TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/loose/cmake/list/build

IMO d should also evaluate to FALSE.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0009043closed Alex Neundorf Use of FindPackageHandleStandardArgs counter-intuitive 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-11-05 12:38Marcel LooseNew Issue
2010-11-05 13:25Alex NeundorfNote Added: 0022901
2010-11-10 12:02David ColeAssigned To => David Cole
2010-11-10 12:02David ColeStatusnew => assigned
2010-11-10 12:02David ColeTarget Version => CMake 2.8.4
2010-11-10 12:03David ColeRelationship addedrelated to 0009043
2010-12-08 13:31Ben BoeckelNote Added: 0023806
2010-12-08 13:32Ben BoeckelAssigned ToDavid Cole => Ben Boeckel
2011-01-05 13:48David ColeNote Added: 0024430
2011-01-05 13:48David ColeStatusassigned => resolved
2011-01-05 13:48David ColeFixed in Version => CMake 2.8.4
2011-01-05 13:48David ColeResolutionopen => won't fix
2011-01-06 03:29Marcel LooseNote Added: 0024445
2011-01-06 03:29Marcel LooseStatusresolved => feedback
2011-01-06 03:29Marcel LooseResolutionwon't fix => reopened
2011-01-06 07:54David ColeNote Added: 0024451
2011-01-06 07:56David ColeNote Added: 0024452
2011-01-06 07:56David ColeStatusfeedback => resolved
2011-01-06 07:56David ColeResolutionreopened => won't fix
2011-05-02 14:45David ColeNote Added: 0026313
2011-05-02 14:45David ColeStatusresolved => closed
2012-08-13 14:36Alex NeundorfNote Added: 0030574
2012-08-13 14:36Alex NeundorfStatusclosed => feedback
2012-08-13 14:36Alex NeundorfResolutionwon't fix => reopened
2012-08-13 14:43Brad KingNote Added: 0030577
2012-08-13 14:52Alex NeundorfNote Added: 0030580
2012-08-13 14:56David ColeNote Added: 0030582
2012-08-13 15:04Brad KingNote Added: 0030583
2012-08-13 15:10Alex NeundorfNote Added: 0030596
2012-08-13 15:26David ColeNote Added: 0030614
2016-06-10 14:28Kitware RobotNote Added: 0041761
2016-06-10 14:28Kitware RobotStatusfeedback => resolved
2016-06-10 14:28Kitware RobotFixed in VersionCMake 2.8.4 =>
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0022901)
Alex Neundorf   
2010-11-05 13:25   
I agree.
I guess we can fix this with a policy ?

Alex
(0023806)
Ben Boeckel   
2010-12-08 13:31   
After talking with Dave and Brad, the current behavior will stay the same. The documentation states:

if(<constant>)

  True if the constant is 1, ON, YES, TRUE, Y, or a non-zero number. False if the constant is 0, OFF, NO, FALSE, N, IGNORE, "", or ends in the suffix '-NOTFOUND'. Named boolean constants are case-insensitive.

The string ends with "-NOTFOUND", so it is false.

Adding the keywords "ALLOF" and "ANYOF" for testing the truth value of lists is my proposal for a fix which Brad and Dave seemed amenable to (they're not likely to be variable names and therefore break existing code).
(0024430)
David Cole   
2011-01-05 13:48   
IF(<LIST>) is not a CMake construct. IF(VARIABLE) is. And it is consistent. The rule for this is simple, and will remain simple. We will not be adding changes to deal with IF(<LIST>) in CMake internals.

You may consider writing a function in the CMake language such as this (not tested, but you should be able to get the idea from this):

function(test_list list result_var)
  foreach(item ${list})
    if(NOT item)
      set(${result_var} 0 PARENT_SCOPE)
      return()
    endif()
  endforeach()
  set(${result_var} 1 PARENT_SCOPE)
endfunction()

set(a "NOTFOUND")
test_list("${a}" ar)
set(b "blub-NOTFOUND")
test_list("${b}" br)
set(c "bar;blub-NOTFOUND")
test_list("${c}" cr)
set(d "blub-NOTFOUND;bar")
test_list("${d}" dr)

Please re-open for more discussion if you really disagree with this resolution, but understand that even if it's re-opened, there's not enough time left to work on this for the 2.8.4 release.
(0024445)
Marcel Loose   
2011-01-06 03:29   
What about Ben's proposal to add the keywords "ALLOF" and "ANYOF"? Is that idea abandoned?
(0024451)
David Cole   
2011-01-06 07:54   
Personally, I have abandoned the idea of ALLOF and ANYOF. I don't think we should add needless complication to the IF command.

If something can be done in a less than 10 line CMake function, I consider it needless complication unless it is absolutely clear that the majority of CMake projects would benefit from it.

This is one of those cases in my opinion, but if there are enough voices of dissent, I will yield to the wisdom of the crowd.

So..... I'm going to resolve this again. If somebody besides Marcel re-opens it, in effect "voting" for it, then I'll leave it open for a future version. Either way, this is not going to be in CMake 2.8.4.
(0024452)
David Cole   
2011-01-06 07:56   
See previous notes. Re-open and set the "target version" to "" if you disagree.
(0026313)
David Cole   
2011-05-02 14:45   
Closing resolved issues that have not been updated in more than 3 months.
(0030574)
Alex Neundorf   
2012-08-13 14:36   
I'm in favour of adding support for testing list contents to if().
(0030577)
Brad King   
2012-08-13 14:43   
I'd like to see a real-world use case for this that is not of the following form:

 find_library(A1 ...)
 find_library(A2 ...)
 set(A_LIBS ${A1} ${A2})

which should be

 find_library(A1 ...)
 find_library(A2 ...)
 if(A1 AND A2)
   set(A_LIBS ${A1} ${A2})
 endif()

or

 foreach(a A1 A2)
   find_library(${a} ...)
   if(${a})
     list(APPEND A_LIBS ${a})
   endif()
 endforeach()

The if(<variable>) form belongs in the code producing the list, not the code using the list.
(0030580)
Alex Neundorf   
2012-08-13 14:52   
IMO, if it is more than 2 variables and the code for setting them is distributed in various places in different if()-blocks or something like that, testing once at the end is a good way to do it.
(0030582)
David Cole   
2012-08-13 14:56   
Alex, if you are re-opening this, then please assign it to yourself, or somebody who can/wants to work on it.

And let's make sure to come to a definitive agreement about what to do before merging stuff to 'next' please.

Thanks.
(0030583)
Brad King   
2012-08-13 15:04   
Re 0011410:0030580: Testing once at the end is not unreasonable (though IMO it is a bad place to test because it has no context for what makes the value false). However, that does not require the way if(variable) works to recognize list values. It can work with the proposed ALLOF/ANYOF modes.

The main issue here IMO is the inconsistency of the results for lists depending on the order and whether the last value happens to be NOTFOUND. This would still a problem even if ALLOF/ANYOF were added. The underlying problem with the case in 0011410:0030577 is that list values should not be tested by if(<constant>) or if(<variable>) modes at all. One solution is to add a policy to reject list-valued values, or to change the way the values are tested to make any value containing ";" considered true. That would remove the inconsistency.
(0030596)
Alex Neundorf   
2012-08-13 15:10   
Re 0011410:0030582 : I thought I could get away cheaply since you wrote "If somebody besides Marcel re-opens it, in effect "voting" for it, then I'll leave it open for a future version."

So, basically this was just a vote for it. :-)
(0030614)
David Cole   
2012-08-13 15:26   
That's fine, but unless it gets assigned to somebody besides Ben, it's just going to the backlog in a week when I analyze bug assignments again.
(0041761)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.