View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0011410 | CMake | CMake | public | 2010-11-05 12:38 | 2016-06-10 14:31 | ||||
Reporter | Marcel Loose | ||||||||
Assigned To | Ben Boeckel | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | CMake 2.8.3 | ||||||||
Target Version | CMake 2.8.4 | Fixed in Version | |||||||
Summary | 0011410: Result of IF(<LIST>) is inconsistent | ||||||||
Description | This 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. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Relationships | ||||||
|
Relationships |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |