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.<br>
<br>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 <br>
<br>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.<br>
<br>--<br>Glenn<br><br><br><div class="gmail_quote">On 9 August 2011 20:34, Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca">irwin@beluga.phys.uvic.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 2011-08-09 17:19+0100 Glenn Coombs wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
so that lines like this:<br>
<br>
set(CMAKE_EXE_LINKER_FLAGS_<u></u>RELEASE "${CMAKE_EXE_LINKER_FLAGS_<u></u>RELEASE} /INCREMENTAL:NO")<br>
<br>
become shorter and easier to understand:<br>
<br>
append(CMAKE_EXE_LINKER_FLAGS_<u></u>RELEASE "/INCREMENTAL:NO")<br>
<br>
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<br>
feel that it should be supported out of the box as it would make CMakeLists.txt files more readable.<br>
<br>
</blockquote>
<br>
Hi Glenn:<br>
<br>
I am changing the subject line to keep discussion out of the<br>
bugfix thread as requested by Dave.<br>
<br>
It appears what you want is the list APPEND command for<br>
blank-delimited strings. But then later someone will want to add<br>
other parts of the list functionality to blank-delimited strings as<br>
well such as removing items from the blank-delimited list. Until you<br>
have two parallel list systems, one for blank delimited strings and<br>
one for semicolon-delimited strings (i.e., the current lists).<br>
<br>
I think most would reject the idea of having two parallel list systems<br>
with different delimiters so here is one possibility.<br>
<br>
For now just stick to list functionality, e.g.,<br>
<br>
list(APPEND CMAKE_EXE_LINKER_FLAGS_RELEASE "/INCREMENTAL:NO")<br>
<br>
and then change the semicolon delimiters to blanks using<br>
<br>
strings(REGEX REPLACE ...)<br>
<br>
once you have the list completely assembled. Of course, that will not<br>
work for the corner case where the strings contain semicolons. So in<br>
the long term, the right thing to do with lists might be to allow a<br>
choice of delimiter if you could do that in such a way as to preserve<br>
backwards compatibility.<br>
<br>
Alan<br>
__________________________<br>
Alan W. Irwin<br>
<br>
Astronomical research affiliation with Department of Physics and Astronomy,<br>
University of Victoria (<a href="http://astrowww.phys.uvic.ca" target="_blank">astrowww.phys.uvic.ca</a>).<br>
<br>
Programming affiliations with the FreeEOS equation-of-state implementation<br>
for stellar interiors (<a href="http://freeeos.sf.net" target="_blank">freeeos.sf.net</a>); PLplot scientific plotting software<br>
package (<a href="http://plplot.org" target="_blank">plplot.org</a>); the libLASi project (<a href="http://unifont.org/lasi" target="_blank">unifont.org/lasi</a>); the Loads of<br>
Linux Links project (<a href="http://loll.sf.net" target="_blank">loll.sf.net</a>); and the Linux Brochure Project<br>
(<a href="http://lbproject.sf.net" target="_blank">lbproject.sf.net</a>).<br>
__________________________<br>
<br>
Linux-powered Science<br>
__________________________<br>
</blockquote></div><br>