[CMake] append command

[Glenn Coombs]

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> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110813/d7a4495a/attachment.htm>