[CMake] append command
Michael Wild
themiwi at gmail.com
Thu Aug 11 14:37:44 EDT 2011
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
More information about the CMake
mailing list