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 <mhertl...@online.de > <mailto: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
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 _______________________________________________ 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