[CMake] append command

[Glenn Coombs]

I was thinking of using the exact same variable names as are currently in
use.  Currently if I do this:

set(CMAKE_C_FLAGS "-foo")
list(APPEND CMAKE_C_FLAGS "-bar")

then it will fail as it tries to run the command "/usr/bin/gcc  -foo;-bar
..." but if cmake automatically replaced semicolons with spaces then it
would work fine.  Existing scripts that used set(CMAKE_C_FLAGS
"${CMAKE_C_FLAGS} -bar") would be unaffected.  And given that the cmake
variables that would be treated this way are passed directly to the
compiler/linker it is exceedingly unlikely that they would contain real
semicolons, at least on linux.  Is the problem with this idea that real
semicolons in flags are necessary on windows or macosx ?

If real semicolons were required they could be escaped with a backslash
character, i.e. set(CMAKE_C_FLAGS "-foo\;-bar") if you didn't want them to
be replaced with a space character.  But that would break the backwards
compatibility rule.  Are there any cmake variables where real semicolons
need to be passed through to the compiler/linker ?

--
Glenn

On 15 August 2011 12:56, David Cole <david.cole at kitware.com> wrote:

> On Aug 13, 2011, at 5:14 AM, Glenn Coombs <glenn.coombs at gmail.com> wrote:
>
> Out of all the suggestions so far I'd like to say that my preferred
> solution is Michael's one of:
>
>     SET(<variable> <value> ... CONCAT [SEP <sep>])
>
> I haven't seen any discussion yet of my 2nd alternative of getting cmake to
> automatically convert lists to space separated strings for certain variables
> like CMAKE_EXE_LINKER_FLAGS_RELEASE.  If cmake did this then there would be
> less need for the concat version of set() as one could just use the existing
> list(APPEND) functionality.  Is this a realistic possibility, or are there
> implementation issues with this suggestion ?
>
>
> No particular implementation issues. Doing any of this stuff is fairly easy
> to implement.
>
> But we won't be changing the semantics of any existing variables or
> properties to accommodate a feature like this... That would be a backwards
> compatibility nightmare.
>
> And that means inventing new variables with the desired semantics, in
> addition to supporting the existing ones. Which makes it very much less
> likely for us to want to do it without a very strong consensus from all
> involved that it really does make things easier, nicer, more maintainable.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110816/a9432146/attachment.htm>