(0022901)
Alex Neundorf (developer)
2010-11-05 13:25

I agree.
I guess we can fix this with a policy ?

Alex

(0023806)
Ben Boeckel (developer)
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 (manager)
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 (developer)
2011-01-06 03:29

What about Ben's proposal to add the keywords "ALLOF" and "ANYOF"? Is that idea abandoned?

(0024451)
David Cole (manager)
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 (manager)
2011-01-06 07:56

See previous notes. Re-open and set the "target version" to "" if you disagree.

(0026313)
David Cole (manager)
2011-05-02 14:45

Closing resolved issues that have not been updated in more than 3 months.

(0030574)
Alex Neundorf (developer)
2012-08-13 14:36

I'm in favour of adding support for testing list contents to if().

(0030577)
Brad King (manager)
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 (developer)
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 (manager)
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 (manager)
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 (developer)
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 (manager)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
2010-11-05 12:38	Marcel Loose	New Issue
2010-11-05 13:25	Alex Neundorf	Note Added: 0022901
2010-11-10 12:02	David Cole	Assigned To	=> David Cole
2010-11-10 12:02	David Cole	Status	new => assigned
2010-11-10 12:02	David Cole	Target Version	=> CMake 2.8.4
2010-11-10 12:03	David Cole	Relationship added	related to 0009043
2010-12-08 13:31	Ben Boeckel	Note Added: 0023806
2010-12-08 13:32	Ben Boeckel	Assigned To	David Cole => Ben Boeckel
2011-01-05 13:48	David Cole	Note Added: 0024430
2011-01-05 13:48	David Cole	Status	assigned => resolved
2011-01-05 13:48	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-05 13:48	David Cole	Resolution	open => won't fix
2011-01-06 03:29	Marcel Loose	Note Added: 0024445
2011-01-06 03:29	Marcel Loose	Status	resolved => feedback
2011-01-06 03:29	Marcel Loose	Resolution	won't fix => reopened
2011-01-06 07:54	David Cole	Note Added: 0024451
2011-01-06 07:56	David Cole	Note Added: 0024452
2011-01-06 07:56	David Cole	Status	feedback => resolved
2011-01-06 07:56	David Cole	Resolution	reopened => won't fix
2011-05-02 14:45	David Cole	Note Added: 0026313
2011-05-02 14:45	David Cole	Status	resolved => closed
2012-08-13 14:36	Alex Neundorf	Note Added: 0030574
2012-08-13 14:36	Alex Neundorf	Status	closed => feedback
2012-08-13 14:36	Alex Neundorf	Resolution	won't fix => reopened
2012-08-13 14:43	Brad King	Note Added: 0030577
2012-08-13 14:52	Alex Neundorf	Note Added: 0030580
2012-08-13 14:56	David Cole	Note Added: 0030582
2012-08-13 15:04	Brad King	Note Added: 0030583
2012-08-13 15:10	Alex Neundorf	Note Added: 0030596
2012-08-13 15:26	David Cole	Note Added: 0030614
2016-06-10 14:28	Kitware Robot	Note Added: 0041761
2016-06-10 14:28	Kitware Robot	Status	feedback => resolved
2016-06-10 14:28	Kitware Robot	Fixed in Version	CMake 2.8.4 =>
2016-06-10 14:28	Kitware Robot	Resolution	reopened => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

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

(0023806) Ben Boeckel (developer) 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 (manager) 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 (developer) 2011-01-06 03:29	What about Ben's proposal to add the keywords "ALLOF" and "ANYOF"? Is that idea abandoned?

(0024451) David Cole (manager) 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 (manager) 2011-01-06 07:56	See previous notes. Re-open and set the "target version" to "" if you disagree.

(0026313) David Cole (manager) 2011-05-02 14:45	Closing resolved issues that have not been updated in more than 3 months.

(0030574) Alex Neundorf (developer) 2012-08-13 14:36	I'm in favour of adding support for testing list contents to if().

(0030577) Brad King (manager) 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 (developer) 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 (manager) 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 (manager) 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 (developer) 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 (manager) 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 (administrator) 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.