MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015529CMakeCMakepublic2015-04-22 09:152016-01-04 11:51
Reportermarc.chevrier 
Assigned ToNils Gladitz 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 3.2.2 
Target VersionCMake 3.3Fixed in VersionCMake 3.3 
Summary0015529: enhance if() to support list
DescriptionCurrently, to test if a list contains an element, the following pattern must be used:
list (FIND my_list ${my_item} is_found)
if (NOT ${is_found} EQUAL -1)
   # item exists in list
endif ()

I suggest to extend if() syntax to support test of existence of an item in a list:
if (<variable|string> IN <list>)

So, the previous test becomes:
if (my_item IN my_list)
  ...
endif ()
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-04-22 09:15marc.chevrierNew Issue
2015-04-27 07:57Nils GladitzNote Added: 0038602
2015-04-27 08:25Brad KingNote Added: 0038603
2015-04-27 08:37Nils GladitzNote Added: 0038604
2015-04-27 08:42Brad KingNote Added: 0038605
2015-04-27 09:11Nils GladitzNote Added: 0038607
2015-04-27 09:23Brad KingNote Added: 0038608
2015-04-27 09:34Nils GladitzNote Added: 0038609
2015-04-27 09:46Brad KingNote Added: 0038611
2015-04-27 10:22Nils GladitzNote Added: 0038616
2015-04-28 09:16Nils GladitzNote Added: 0038626
2015-04-28 09:38Nils GladitzNote Added: 0038627
2015-04-29 14:57herc4macNote Added: 0038642
2015-04-29 15:00Brad KingNote Added: 0038643
2015-04-29 15:02herc4macNote Added: 0038644
2015-04-30 10:34Brad KingNote Added: 0038660
2015-04-30 10:35Brad KingAssigned To => Nils Gladitz
2015-04-30 10:35Brad KingStatusnew => resolved
2015-04-30 10:35Brad KingResolutionopen => fixed
2015-04-30 10:35Brad KingFixed in Version => CMake 3.3
2015-04-30 10:35Brad KingTarget Version => CMake 3.3
2015-04-30 16:28Stephen KellyNote Added: 0038671
2015-04-30 16:43Nils GladitzNote Added: 0038672
2016-01-04 11:51Robert MaynardNote Added: 0040066
2016-01-04 11:51Robert MaynardStatusresolved => closed

Notes
(0038602)
Nils Gladitz   
2015-04-27 07:57   
Can this be implemented without a new policy?
(0038603)
Brad King   
2015-04-27 08:25   
Re 0015529:0038602: I don't think so. Any new operation in if() needs a policy because the "keyword" associated with it could currently be interpreted as something different.
(0038604)
Nils Gladitz   
2015-04-27 08:37   
Thanks. I wouldn't mind trying to implement this unless anyone objects.

For the suggested signature:
  if (<variable|string> IN <list>)

I assume <list> is meant to be <variable> and meant to exclude <string>?
(That is the interpretation that I would prefer)

e.g.

set(MY_LIST foo bar)

legal:
  if("foo" IN MY_LIST)

not legal:
  if("foo" IN "${MY_LIST}")
(0038605)
Brad King   
2015-04-27 08:42   
Re 0015529:0038604: Yes. The list() command treats lists by the variable name containing them.

I think the new operation should be named as "IN_LIST" to indicate the "type" of the value expected to come on the right. Otherwise one might think it is supposed to look for a substring or something.

FWIW, one can achieve this test currently with

 if(";${MY_LIST};" MATCHES ";foo;")
(0038607)
Nils Gladitz   
2015-04-27 09:11   
I am trying to come up with a test case for the policy warning but can't think of a case where use of IN_LIST would actually be ambiguous.

e.g. if(foo IN_LIST MY_LIST) is not syntactically valid with the old behavior (Unknown arguments specified).

Any ideas?
(0038608)
Brad King   
2015-04-27 09:23   
Re 0015529:0038607: Actually maybe it is only the unary operators like "EXISTS" and "IS_ABSOLUTE" that have this problem. I haven't thought thoroughly about it though.
(0038609)
Nils Gladitz   
2015-04-27 09:34   
Hm do you have an example for an ambiguity that might occur with the unary operators (maybe something can be extrapolated for binary operators)?

e.g. given a hypothetical new unary operator FOOBAR

if(FOOBAR "test") would still produce "Unknown arguments specified" with OLD behaviour.
(0038611)
Brad King   
2015-04-27 09:46   
There was an attempt at adding "if(TEST <name>)" to check if add_test has been called for a given test. It broke cases where "TEST" was already used as a variable name and had to be reverted. See this commit and its first few ancestors:

 Revert topic 'if-test'
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=40b69cea [^]

A policy will be needed for that one too.
(0038616)
Nils Gladitz   
2015-04-27 10:22   
Thanks, took me a bit to figure out given that e.g. EXISTS seems to work as a variable/string as well in e.g.:

 set(EXISTS true)
 if(EXISTS)

But a unary case that is ambiguous is e.g.:
  if(EXISTS STREQUAL "foo")

Still missing a binary case though.
(0038626)
Nils Gladitz   
2015-04-28 09:16   
I pushed my implementation to github for now:
https://github.com/ngladitz/cmake/commit/14ffb04b132736133e1d16b0baa879414f733fe5 [^]

Not sure how to proceed from here ... I still haven't been able to find a proper
test case for the policy warning and I am not sure if there is or isn't one.
(0038627)
Nils Gladitz   
2015-04-28 09:38   
I just realized that I could cover the warning in the error case as well.
I revised the topic accordingly and merged to next for testing.
(0038642)
herc4mac   
2015-04-29 14:57   
I am fond of symmetries

why not use the same constructs as foreach

if( variable IN LISTS ... ... ... )
if( variable IN ITEMS ... ... ... )

my best regards
enrico
(0038643)
Brad King   
2015-04-29 15:00   
Re 0015529:0038642: We can't use an open ended expression like that because in if(), unlike in foreach(), expressions can be nested:

 if(foo IN_LIST mylist AND other_condition)
(0038644)
herc4mac   
2015-04-29 15:02   
oops,
sorry for the oversight!
enrico
(0038660)
Brad King   
2015-04-30 10:34   
This has been implemented here:

 if: Implement new IN_LIST operator
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aed6239e [^]
(0038671)
Stephen Kelly   
2015-04-30 16:28   
If the old behavior is an error, then why add the policy?

All other policies are for code which has a non-error case. That is the whole point.

Adding features without policies for code which used to be an error before is a quite-central concept in cmake compatibility design.

Why is this different? Is it 'there might be a non-error case which we can't imagine'?
(0038672)
Nils Gladitz   
2015-04-30 16:43   
Yes, I couldn't think of an ambiguous case for the unary operator at first either.

Even though I couldn't come up with an ambiguity in the binary case I wasn't certain enough to argue against the policy.
(0040066)
Robert Maynard   
2016-01-04 11:51   
Closing resolved issues that have not been updated in more than 4 months.