On 08/11/2011 07:48 PM, Michael Hertling wrote: > On 08/11/2011 05:20 PM, Michael Wild wrote: >> On Thu 11 Aug 2011 04:46:44 PM CEST, David Cole wrote: >>> On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs <glenn.coo...@gmail.com >>> <mailto:glenn.coo...@gmail.com>> wrote: >>> >>> The problem is that we currently already have 2 parallel systems. >>> Some of the variables like CMAKE_EXE_LINKER_FLAGS are passed through >>> as-is to the compiler or linker. So, by definition, these variables >>> are space separated lists of options. Attempting to use >>> list(APPEND) on them adds semicolon characters which causes breakage >>> unless you manually remove them. >>> >>> Using list(APPEND), followed by string(REGEX REPLACE) is even more >>> verbose than just using the set(foo "${foo} ...") approach. I see >>> an append() command as just the equivalent of the += operator in >>> C/C++ and don't think that adding it would necessarily require >>> adding any more space separated list functionality. And I agree >>> that you wouldn't really want >>> >>> An alternative approach (but harder to implement) would be to >>> abandon space separated lists altogether. Variables like >>> CMAKE_EXE_LINKER_FLAGS would be stored as lists and then cmake would >>> format them internally as space separated strings before passing >>> them to the native build tools. You might have to change the way >>> cmake internally represents lists if you ever wanted to be able to >>> pass options with semicolons through to the build tools. >>> >>> -- >>> Glenn >>> >>> >>> >>> On 9 August 2011 20:34, Alan W. Irwin <ir...@beluga.phys.uvic.ca >>> <mailto:ir...@beluga.phys.uvic.ca>> wrote: >>> >>> On 2011-08-09 17:19+0100 Glenn Coombs wrote: >>> >>> Probably too late now and there isn't a bug filed so far as >>> I know, but one thing I would love to see added to cmake is >>> an append command >>> so that lines like this: >>> >>> set(CMAKE_EXE_LINKER_FLAGS_ RELEASE >>> "${CMAKE_EXE_LINKER_FLAGS_ RELEASE} /INCREMENTAL:NO") >>> >>> become shorter and easier to understand: >>> >>> append(CMAKE_EXE_LINKER_FLAGS_ RELEASE "/INCREMENTAL:NO") >>> >>> The existing syntax for the set command is just ugly when >>> appending. I know you can define a macro or function to do >>> this but I just >>> feel that it should be supported out of the box as it would >>> make CMakeLists.txt files more readable. >>> >>> >>> Hi Glenn: >>> >>> I am changing the subject line to keep discussion out of the >>> bugfix thread as requested by Dave. >>> >>> It appears what you want is the list APPEND command for >>> blank-delimited strings. But then later someone will want to add >>> other parts of the list functionality to blank-delimited strings as >>> well such as removing items from the blank-delimited list. >>> Until you >>> have two parallel list systems, one for blank delimited strings and >>> one for semicolon-delimited strings (i.e., the current lists). >>> >>> I think most would reject the idea of having two parallel list >>> systems >>> with different delimiters so here is one possibility. >>> >>> For now just stick to list functionality, e.g., >>> >>> list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE "/INCREMENTAL:NO") >>> >>> and then change the semicolon delimiters to blanks using >>> >>> strings(REGEX REPLACE ...) >>> >>> once you have the list completely assembled. Of course, that >>> will not >>> work for the corner case where the strings contain semicolons. So in >>> the long term, the right thing to do with lists might be to allow a >>> choice of delimiter if you could do that in such a way as to >>> preserve >>> backwards compatibility. >>> >>> Alan >>> __________________________ >>> Alan W. Irwin >>> >>> Astronomical research affiliation with Department of Physics and >>> Astronomy, >>> University of Victoria (astrowww.phys.uvic.ca >>> <http://astrowww.phys.uvic.ca>). >>> >>> Programming affiliations with the FreeEOS equation-of-state >>> implementation >>> for stellar interiors (freeeos.sf.net <http://freeeos.sf.net>); >>> PLplot scientific plotting software >>> package (plplot.org <http://plplot.org>); the libLASi project >>> (unifont.org/lasi <http://unifont.org/lasi>); the Loads of >>> Linux Links project (loll.sf.net <http://loll.sf.net>); and the >>> Linux Brochure Project >>> (lbproject.sf.net <http://lbproject.sf.net>). >>> __________________________ >>> >>> Linux-powered Science >>> __________________________ >>> >>> >>> >>> Until somebody comes up with an approach that is reasonably acceptable >>> by consensus, we will keep things as they are. Please use the (verbose, >>> but easily understandable) current form for the foreseeable future: >>> >>> set(xyz "${xyz} /newstuff") >>> >>> (I am personally adamantly opposed to an actual "append" command because >>> of the existence of the "list(APPEND" feature... I think "append" will >>> cause even more confusion...) >>> >>> >>> Thanks, >>> David Cole >>> Kitware, Inc. >> >> How about >> >> string(APPEND " /newstuff" xyz) >> >> It is not satisfactory in that it doesn't follow the semantics of all >> the other string(...) commands which never modify their input. >> >> Michael > > As David has implied, "APPEND" is usually associated with lists, cf. > LIST(APPEND ...) and SET_PROPERTY(... APPEND ...), so I'd prefer to > name this subcommand "CONCAT", e.g. > > STRING(CONCAT <output variable> [SEP <sep>] <input> ...) > > which is to be equivalent to > > SET(<output variable> "${<output variable>}<sep><input>...") > > with <sep> defaulting to a single space if it's unspecified. > > 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>...") > > again with <sep> defaulting to a space. This would preserve the > STRING() command's strict distinction between input and output > variables. Anyway, I agree that this whole APPEND/CONCAT issue > isn't a serious problem but just a convenience feature. > > 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. > > Regards, > > Michael
Just one concern: CONCAT does not imply "+=" for me, so the name could possibly also be confusing. 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
