MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014583CMakeCMakepublic2013-11-19 10:072016-06-10 14:31
ReporterJean-Christophe Fillion-Robin 
Assigned ToKitware Robot 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0014583: Add convenience function to convert list into a string with a chosen separator
DescriptionA possible signature could be:

function(list_to_string separator input_list output_string_var)
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0014177closed Kitware Robot RFE: built-in to join list of strings 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2013-11-19 10:07Jean-Christophe Fillion-RobinNew Issue
2013-11-19 10:14Brad KingNote Added: 0034479
2013-11-19 11:18Jean-Christophe Fillion-RobinNote Added: 0034481
2013-11-19 12:17Jean-Christophe Fillion-RobinNote Added: 0034487
2013-11-19 12:28Rolf Eike BeerNote Added: 0034488
2013-11-19 12:33mwoehlkeRelationship addedduplicate of 0014177
2013-11-19 12:38mwoehlkeNote Added: 0034489
2013-11-19 12:47Brad KingNote Added: 0034490
2013-11-19 13:26mwoehlkeNote Added: 0034491
2013-11-19 13:39Brad KingNote Added: 0034492
2013-11-19 14:39mwoehlkeNote Added: 0034493
2013-11-19 14:49Jean-Christophe Fillion-RobinNote Added: 0034494
2013-11-19 15:03Brad KingNote Added: 0034495
2016-06-10 14:29Kitware RobotNote Added: 0042430
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0034479)
Brad King   
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   
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   
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   
2013-11-19 12:28   
What about list(JOIN <list> <separator> <output variable>)? I find TO_STRING a bit too general.
(0034489)
mwoehlke   
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   
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   
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   
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   
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   
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   
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   
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.