[CMake] append command

[Michael Hertling]

On 08/11/2011 08:37 PM, Michael Wild wrote:
> 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.coombs at gmail.com
>>>> <mailto:glenn.coombs at 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 <irwin at beluga.phys.uvic.ca
>>>>     <mailto:irwin at 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

Strictly speaking, you are right, but look at the C standard library's
strcat() and strncat() functions; beside their return value, they have
the typical "+=" semantics and inspired me to suggest the term "CONCAT"
as they do what's discussed here for the STRING() or SET() command. In
the end, one might choose whatever seems suitable, but it shouldn't be
APPEND, and APPEND_STRING for SET_PROPERTY() is also unfortunate, IMO.

Regards,

Michael