On Aug 13, 2011, at 5:14 AM, Glenn Coombs <glenn.coo...@gmail.com> 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 ?
No particular implementation issues. Doing any of this stuff is fairly easy to
implement.
But we won't be changing the semantics of any existing variables or properties
to accommodate a feature like this... That would be a backwards compatibility
nightmare.
And that means inventing new variables with the desired semantics, in addition
to supporting the existing ones. Which makes it very much less likely for us to
want to do it without a very strong consensus from all involved that it really
does make things easier, nicer, more maintainable.
Thanks for the discussion,
David
>
> --
> Glenn
>
>
> On 12 August 2011 05:16, Michael Hertling <mhertl...@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
>
> _______________________________________________
> 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
_______________________________________________
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
