[CMake] append command

[Michael Wild]

On Sat 13 Aug 2011 11:14:52 AM CEST, Glenn Coombs wrote:
> Out of all the suggestions so far I'd like to say that my preferred
> solution is Michael's one of:
> 
>     SET(<variable> <value> ... CONCAT [SEP <sep>])
> 
> I haven't seen any discussion yet of my 2nd alternative of getting cmake
> to automatically convert lists to space separated strings for certain
> variables like CMAKE_EXE_LINKER_FLAGS_RELEASE.  If cmake did this then
> there would be less need for the concat version of set() as one could
> just use the existing list(APPEND) functionality.  Is this a realistic
> possibility, or are there implementation issues with this suggestion ?
> 
> --
> Glenn
> 
> 
> On 12 August 2011 05:16, Michael Hertling <mhertling at online.de
> <mailto:mhertling at online.de>> wrote:
> 
>     On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
>     > On Thursday 11 August 2011, Michael Hertling wrote:
>     > ...
>     >> Alternatively, one might consider to introduce a new, say,
>     >> modifier "CONCAT" for the SET() command, e.g.
>     >>
>     >> SET(<variable> <value> ... CONCAT [SEP <sep>])
>     >>
>     >> equivalent to
>     >>
>     >> SET(<variable> "${<variable>}<sep><value>...")
>     >
>     > I'm not sure this is actually necessary.
>     > Personally I'm fine with
>     > set(foo "${foo} bar")
>     > It's just one line. For properties more code is needed otherwise.
> 
>     So far, I also don't need such a string concatenation feature, but
> 
>     LIST(APPEND ...)
> 
>     and
> 
>     SET_PROPERTY(... APPEND/APPEND_STRING ...)
> 
>     aren't actually necessary, too, but convenient, so I would not be
>     opposed to another convenience feature for concatenating strings.
> 
>     >> Besides, David, due to the same reasons as mentioned above, the new
>     >> APPEND_STRING subcommand of SET_PROPERTY() is quite misnamed, IMO -
>     >> and quite long. Would it be possible to rename it to CONCAT before
>     >> it is released officially? In this way, we would consistently have
>     >> APPEND subcommands for list-style variables/properties and CONCAT
>     >> subcommands for string-style ones.
>     >
>     > We can do that, if other people think also that this would be a
>     better name.
>     > Or "STRING_APPEND" instead of "APPEND_STRING" ?
> 
>     The crucial point is that the subcommand/modifier for concatenating
>     strings - regardless for which command(s) it is implemented - should
> 
>     - not be named "APPEND" because this term is already in use for lists,
>      and there's at least one occasion where a list-related and a string-
>      related "+=" operation are about to coincide, namely SET_PROPERTY().
>     - be named the same in all commands that provide - or possibly will
>      provide - this functionality. SET_PROPERTY() is going to name it
>      APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
>      result in inconsistent CMakeLists.txt code if there'll be a SET()
>      or STRING() implementation for concatenating strings: Certainly,
>      one would not want to call the latter SET(... APPEND_STRING) or
>      STRING(STRING_APPEND ...), so one ends up with two differently
>      named subcommands/modifiers for the same kind of operation.
> 
>     For this reason, I'd recommend to reconsider the APPEND_STRING sub-
>     command's naming and change it to a term that's also suitable for
>     a string concatenation feature in other CMake commands - just to
>     leave the door open. Therefor, my suggestion is CONCAT.
> 
>     Regards,
> 
>     Michael

To be honest, the only occasion where I miss a more concise command is 
when I have pretty long variable names and it becomes essentially 
impossible to stay within a 80-columns line length limit.

Michael