[CMake] append command

[Michael Hertling]

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