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
>>>             become shorter and easier to understand:
>>>             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.,
>>>         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.


Powered by www.kitware.com

Visit other Kitware open-source projects at 

Please keep messages on-topic and check the CMake FAQ at: 

Follow this link to subscribe/unsubscribe:

Reply via email to