(0034479)
Brad King (manager)
2013-11-19 10:14

This should be added as a subcommand to list() or string() rather than as a new command.

(0034481)
Jean-Christophe Fillion-Robin (reporter)
2013-11-19 11:18

Agreed.

In the mean time, I contributed the "function" based approach that I originally developed for Slicer build system. See [1] and [2]

Considering it is also associated with an exhaustive test suite, it could serve as a good base to re-implement it using the subcommand approach.

[1] https://github.com/jcfr/CMake/tree/14583-add-list-to-string-module [^]

[2] https://github.com/Slicer/Slicer/blob/master/CMake/ListToString.cmake [^]

(0034487)
Jean-Christophe Fillion-Robin (reporter)
2013-11-19 12:17

Took the time to implement it as a TO_STRING subcommand. Still need to move the test around and add documentation.

See https://github.com/jcfr/CMake/commit/2cf42c774c4989b1483712833b5a2352576eae96 [^]

So far the signature is:

list(TO_STRING <list> <separator> <output variable>)

would it makes sense to instead have a signature like this one:

list(TO_STRING <list> <output variable> [SEPARATOR <separator>])

with default value for <separator> being "^^" or something else ?

(0034488)
Rolf Eike Beer (developer)
2013-11-19 12:28

What about list(JOIN <list> <separator> <output variable>)? I find TO_STRING a bit too general.

(0034489)
mwoehlke (developer)
2013-11-19 12:38

I vote for 'list({JOIN|TO_STRING} <output> <separator> <items...>)'. Like e.g. list(APPEND) I prefer to have the output variable first for consistency, and that it shall accept a list of items, not a variable that is a list.

(0034490)
Brad King (manager)
2013-11-19 12:47

Re 0014583:0034489: If it accepts a list of items as arguments rather than a variable that names a list then it should be in the string() command. That recently learned a CONCAT subcommand that is just like the proposed JOIN except that it has no separator.

(0034491)
mwoehlke (developer)
2013-11-19 13:26

Two questions then:

1. Is string(CONCAT) new in 3.0? (I don't see it in 2.8.12.1?) If yes, should it just also take a separator always? (Alternatives: string(JOIN), string(CONCAT SEPARATOR). I actually have some preference to string(JOIN) instead. Though of course it makes string(CONCAT) somewhat redundant...)

2. Is there any added value to a variant that takes a list variable vs. passing the list by unquoted expansion? (See e.g. 0014177 where taking a pre-expanded list allows ';' to appear in items which is not otherwise possible; is there a converse case?)

(0034492)
Brad King (manager)
2013-11-19 13:39

Re 0014583:0034491: Yes, string(CONCAT) is new. It could be changed to string(JOIN) but it may be clearer to use CONCAT rather than JOIN with an empty separator.

There are use cases both for joining arguments and for joining lists in named variables. The former belongs in the string() command and the latter in the list() command. Perhaps we need two new subcommands:

string(JOIN <separator> <output variable> [<input>...])

list(JOIN <list> <separator> <output variable>)

Note the order of the arguments in this proposal for each case matches the convention already in use in the respective string/list command.

(0034493)
mwoehlke (developer)
2013-11-19 14:39

Huh. So it does; it feels strange that the output variable isn't always in the same place (I don't use the other list sumcommands enough; I had to look them up to verify that yes, the list really always is first, even though it's sometimes an IVAR and sometimes an OVAR). That being the case, I retract my earlier proposal for the syntax; okay with this one. However...

I agree that string(CONCAT) has better clarity, just "wondering alound" if that justifies a subcommand for something that is trivially accomplished in another way. Similar with list(JOIN); is there a case that list(JOIN) handles that is not handled by string(JOIN) / string(REPLACE), or is it likewise just better clarity of intent?

(0034494)
Jean-Christophe Fillion-Robin (reporter)
2013-11-19 14:49

Do we agree on:

list(JOIN <list> <separator> <output variable>)

If we want in place update, we could have the following signature instead:

list(JOIN <list> <separator> [<output variable>])

(0034495)
Brad King (manager)
2013-11-19 15:03

Re 0014583:0034494: I think we agree on the first one. The "in-place" does not make sense because it is no longer a list after joining. One could always write

list(JOIN myvar "," myvar)

to get the effect of an in-place update.

(0042430)
Kitware Robot (administrator)
2016-06-10 14:29

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
(0034479) Brad King (manager) 2013-11-19 10:14	This should be added as a subcommand to list() or string() rather than as a new command.

(0034481) Jean-Christophe Fillion-Robin (reporter) 2013-11-19 11:18	Agreed. In the mean time, I contributed the "function" based approach that I originally developed for Slicer build system. See [1] and [2] Considering it is also associated with an exhaustive test suite, it could serve as a good base to re-implement it using the subcommand approach. [1] https://github.com/jcfr/CMake/tree/14583-add-list-to-string-module [^] [2] https://github.com/Slicer/Slicer/blob/master/CMake/ListToString.cmake [^]

(0034487) Jean-Christophe Fillion-Robin (reporter) 2013-11-19 12:17	Took the time to implement it as a TO_STRING subcommand. Still need to move the test around and add documentation. See https://github.com/jcfr/CMake/commit/2cf42c774c4989b1483712833b5a2352576eae96 [^] So far the signature is: list(TO_STRING <list> <separator> <output variable>) would it makes sense to instead have a signature like this one: list(TO_STRING <list> <output variable> [SEPARATOR <separator>]) with default value for <separator> being "^^" or something else ?

(0034488) Rolf Eike Beer (developer) 2013-11-19 12:28	What about list(JOIN <list> <separator> <output variable>)? I find TO_STRING a bit too general.

(0034489) mwoehlke (developer) 2013-11-19 12:38	I vote for 'list({JOIN\|TO_STRING} <output> <separator> <items...>)'. Like e.g. list(APPEND) I prefer to have the output variable first for consistency, and that it shall accept a list of items, not a variable that is a list.

(0034490) Brad King (manager) 2013-11-19 12:47	Re 0014583:0034489: If it accepts a list of items as arguments rather than a variable that names a list then it should be in the string() command. That recently learned a CONCAT subcommand that is just like the proposed JOIN except that it has no separator.

(0034491) mwoehlke (developer) 2013-11-19 13:26	Two questions then: 1. Is string(CONCAT) new in 3.0? (I don't see it in 2.8.12.1?) If yes, should it just also take a separator always? (Alternatives: string(JOIN), string(CONCAT SEPARATOR). I actually have some preference to string(JOIN) instead. Though of course it makes string(CONCAT) somewhat redundant...) 2. Is there any added value to a variant that takes a list variable vs. passing the list by unquoted expansion? (See e.g. 0014177 where taking a pre-expanded list allows ';' to appear in items which is not otherwise possible; is there a converse case?)

(0034492) Brad King (manager) 2013-11-19 13:39	Re 0014583:0034491: Yes, string(CONCAT) is new. It could be changed to string(JOIN) but it may be clearer to use CONCAT rather than JOIN with an empty separator. There are use cases both for joining arguments and for joining lists in named variables. The former belongs in the string() command and the latter in the list() command. Perhaps we need two new subcommands: string(JOIN <separator> <output variable> [<input>...]) list(JOIN <list> <separator> <output variable>) Note the order of the arguments in this proposal for each case matches the convention already in use in the respective string/list command.

(0034493) mwoehlke (developer) 2013-11-19 14:39	Huh. So it does; it feels strange that the output variable isn't always in the same place (I don't use the other list sumcommands enough; I had to look them up to verify that yes, the list really always is first, even though it's sometimes an IVAR and sometimes an OVAR). That being the case, I retract my earlier proposal for the syntax; okay with this one. However... I agree that string(CONCAT) has better clarity, just "wondering alound" if that justifies a subcommand for something that is trivially accomplished in another way. Similar with list(JOIN); is there a case that list(JOIN) handles that is not handled by string(JOIN) / string(REPLACE), or is it likewise just better clarity of intent?

(0034494) Jean-Christophe Fillion-Robin (reporter) 2013-11-19 14:49	Do we agree on: list(JOIN <list> <separator> <output variable>) If we want in place update, we could have the following signature instead: list(JOIN <list> <separator> [<output variable>])

(0034495) Brad King (manager) 2013-11-19 15:03	Re 0014583:0034494: I think we agree on the first one. The "in-place" does not make sense because it is no longer a list after joining. One could always write list(JOIN myvar "," myvar) to get the effect of an in-place update.

(0042430) Kitware Robot (administrator) 2016-06-10 14:29	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
2013-11-19 10:07	Jean-Christophe Fillion-Robin	New Issue
2013-11-19 10:14	Brad King	Note Added: 0034479
2013-11-19 11:18	Jean-Christophe Fillion-Robin	Note Added: 0034481
2013-11-19 12:17	Jean-Christophe Fillion-Robin	Note Added: 0034487
2013-11-19 12:28	Rolf Eike Beer	Note Added: 0034488
2013-11-19 12:33	mwoehlke	Relationship added	duplicate of 0014177
2013-11-19 12:38	mwoehlke	Note Added: 0034489
2013-11-19 12:47	Brad King	Note Added: 0034490
2013-11-19 13:26	mwoehlke	Note Added: 0034491
2013-11-19 13:39	Brad King	Note Added: 0034492
2013-11-19 14:39	mwoehlke	Note Added: 0034493
2013-11-19 14:49	Jean-Christophe Fillion-Robin	Note Added: 0034494
2013-11-19 15:03	Brad King	Note Added: 0034495
2016-06-10 14:29	Kitware Robot	Note Added: 0042430
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed