On Monday 15 August 2011, John Drescher wrote:
Anybody else has an opinion on this ?
My preference is to drop the idea since the set command already allows
you to append a string.
I meant for set_property(), not for set().
IMO for set_property() it makes sense, since there it replaces not
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
On Aug 13, 2011, at 2:57 PM, Clifford Yapp cliffy...@gmail.com wrote:
On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
I haven't seen any discussion yet of my 2nd alternative of getting cmake to
automatically convert lists to space separated strings for certain
On Mon, Aug 15, 2011 at 7:59 AM, David Cole david.c...@kitware.com wrote:
Again, our main concern here will be backward compatibility, not difficulty
of encoding semi-colons...
There are tons of real-world projects that already use all of these variables
and properties being discussed with
On Friday 12 August 2011, Michael Hertling wrote:
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
Alternatively, one might consider to introduce a new, say,
modifier CONCAT for the SET() command, e.g.
SET(variable value ...
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
On Sat 13 Aug 2011 11:14:52 AM CEST, Glenn Coombs 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
Which is precisely the sort of thing that started this whole discussion :-)
In the same way that C/C++ would still work without the += operator it does
allow a wonderful conciseness that I miss on occasion. Especially given
cmake's propensity for verbose variable names.
On 13 August 2011 10:22,
On Sat, Aug 13, 2011 at 5:14 AM, Glenn Coombs glenn.coo...@gmail.com wrote:
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
I just wrote my own macro append_property(type name value) for this.
example:
append_property(SOURCE COMPILE_FLAGS -x objective-c++
translate.cpp stuff.cpp)
or
append_property(TARGET COMPILE_FLAGS foo mytarget)
etc
Would be nice to have that as an included macro, or at least a comment in
the
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
On Thu, Aug 11, 2011 at 7:29 AM, Glenn Coombs glenn.coo...@gmail.comwrote:
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
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
On 2011-08-11 17:20+0200 Michael Wild wrote:
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.
I like that idea, but I would generalize it as
string(APPEND string
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
On 08/11/2011 07:39 PM, Alan W. Irwin wrote:
On 2011-08-11 17:20+0200 Michael Wild wrote:
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.
I like that idea, but I
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.coo...@gmail.com
mailto:glenn.coo...@gmail.com wrote:
The problem is that we currently
On Thursday 11 August 2011, Michael Hertling wrote:
...
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}sepvalue...)
I'm not sure this is actually
On Thu, Aug 11, 2011 at 4:31 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:
On 2011-08-11 20:34+0200 Michael Wild wrote:
On 08/11/2011 07:39 PM, Alan W. Irwin wrote:
On 2011-08-11 17:20+0200 Michael Wild wrote:
How about
string(APPEND /newstuff xyz)
It is not satisfactory in that
On Thu, Aug 11, 2011 at 5:28 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote:
On 2011-08-11 16:46-0400 David Cole wrote:
I share Alex's confusion with your proposed signature. All other string
subcommands refer to either string or input in their args
list. None of them have both string
On 2011-08-11 17:35-0400 David Cole wrote:
It's clear what you mean with the REGEX signatures, but I disagree about the
optional nature of at least one input.
In my experience, the lack of an input to one of these signatures usually means
there's a typo in a dereferenced variable name, or
On 08/11/2011 10:04 PM, Alexander Neundorf wrote:
On Thursday 11 August 2011, Michael Hertling wrote:
...
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
On Tue, Aug 9, 2011 at 3:34 PM, Alan W. Irwin 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:
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}
24 matches
Mail list logo