(0038602)
Nils Gladitz (developer)
2015-04-27 07:57

Can this be implemented without a new policy?

(0038603)
Brad King (manager)
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 (developer)
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 (manager)
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 (developer)
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 (manager)
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 (developer)
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 (manager)
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 (developer)
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 (developer)
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 (developer)
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 (reporter)
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 (manager)
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 (reporter)
2015-04-29 15:02

oops,
sorry for the oversight!
enrico

(0038660)
Brad King (manager)
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 (developer)
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 (developer)
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 (manager)
2016-01-04 11:51

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

Notes
(0038602) Nils Gladitz (developer) 2015-04-27 07:57	Can this be implemented without a new policy?

(0038603) Brad King (manager) 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 (developer) 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 (manager) 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 (developer) 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 (manager) 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 (developer) 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 (manager) 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 (developer) 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 (developer) 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 (developer) 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 (reporter) 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 (manager) 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 (reporter) 2015-04-29 15:02	oops, sorry for the oversight! enrico

(0038660) Brad King (manager) 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 (developer) 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 (developer) 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 (manager) 2016-01-04 11:51	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2015-04-22 09:15	marc.chevrier	New Issue
2015-04-27 07:57	Nils Gladitz	Note Added: 0038602
2015-04-27 08:25	Brad King	Note Added: 0038603
2015-04-27 08:37	Nils Gladitz	Note Added: 0038604
2015-04-27 08:42	Brad King	Note Added: 0038605
2015-04-27 09:11	Nils Gladitz	Note Added: 0038607
2015-04-27 09:23	Brad King	Note Added: 0038608
2015-04-27 09:34	Nils Gladitz	Note Added: 0038609
2015-04-27 09:46	Brad King	Note Added: 0038611
2015-04-27 10:22	Nils Gladitz	Note Added: 0038616
2015-04-28 09:16	Nils Gladitz	Note Added: 0038626
2015-04-28 09:38	Nils Gladitz	Note Added: 0038627
2015-04-29 14:57	herc4mac	Note Added: 0038642
2015-04-29 15:00	Brad King	Note Added: 0038643
2015-04-29 15:02	herc4mac	Note Added: 0038644
2015-04-30 10:34	Brad King	Note Added: 0038660
2015-04-30 10:35	Brad King	Assigned To	=> Nils Gladitz
2015-04-30 10:35	Brad King	Status	new => resolved
2015-04-30 10:35	Brad King	Resolution	open => fixed
2015-04-30 10:35	Brad King	Fixed in Version	=> CMake 3.3
2015-04-30 10:35	Brad King	Target Version	=> CMake 3.3
2015-04-30 16:28	Stephen Kelly	Note Added: 0038671
2015-04-30 16:43	Nils Gladitz	Note Added: 0038672
2016-01-04 11:51	Robert Maynard	Note Added: 0040066
2016-01-04 11:51	Robert Maynard	Status	resolved => closed

Relationships