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
_______________________________________________
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
