Re: [CMake] append command

2011-08-16 Thread Alexander Neundorf
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 only one 
line of code and avoids creating an additional temporary variable.

Alex
___
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

Re: [CMake] append command

2011-08-16 Thread 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.c...@kitware.com wrote:

 On Aug 13, 2011, at 5:14 AM, Glenn Coombs glenn.coo...@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.

___
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

Re: [CMake] append command

2011-08-15 Thread David Cole
On Aug 13, 2011, at 5:14 AM, Glenn Coombs glenn.coo...@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.


Thanks for the discussion,
David


 
 --
 Glenn
 
 
 On 12 August 2011 05:16, Michael Hertling mhertl...@online.de 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 ... CONCAT [SEP sep])
 
  equivalent to
 
  SET(variable ${variable}sepvalue...)
 
  I'm not sure this is actually necessary.
  Personally I'm fine with
  set(foo ${foo} bar)
  It's just one line. For properties more code is needed otherwise.
 
 So far, I also don't need such a string concatenation feature, but
 
 LIST(APPEND ...)
 
 and
 
 SET_PROPERTY(... APPEND/APPEND_STRING ...)
 
 aren't actually necessary, too, but convenient, so I would not be
 opposed to another convenience feature for concatenating strings.
 
  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.
 
  We can do that, if other people think also that this would be a better name.
  Or STRING_APPEND instead of APPEND_STRING ?
 
 The crucial point is that the subcommand/modifier for concatenating
 strings - regardless for which command(s) it is implemented - should
 
 - not be named APPEND because this term is already in use for lists,
  and there's at least one occasion where a list-related and a string-
  related += operation are about to coincide, namely SET_PROPERTY().
 - be named the same in all commands that provide - or possibly will
  provide - this functionality. SET_PROPERTY() is going to name it
  APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
  result in inconsistent CMakeLists.txt code if there'll be a SET()
  or STRING() implementation for concatenating strings: Certainly,
  one would not want to call the latter SET(... APPEND_STRING) or
  STRING(STRING_APPEND ...), so one ends up with two differently
  named subcommands/modifiers for the same kind of operation.
 
 For this reason, I'd recommend to reconsider the APPEND_STRING sub-
 command's naming and change it to a term that's also suitable for
 a string concatenation feature in other CMake commands - just to
 leave the door open. Therefor, my suggestion is CONCAT.
 
 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
 
 ___
 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
___
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

Re: [CMake] append command

2011-08-15 Thread David Cole


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 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 ?
 
 This surprised me as well - if you want to assemble a list of flags
 on the fly (I needed to assemble lists of lists of flags - we pass a
 lot of them) you have to take some care to either do the set trick
 correctly or convert the list to a string at the end (if you can be
 sure of where that is).
 
 Do I understand correctly that the main concern is the ability to pass
 args with ;' characters in these cases?  Then the question becomes
 whether quoting ; characters as needed in user-specified options is
 tricker than navigating the current behavior.  To be honest, I can see
 where trying to specify an argument with a quoted ; character from
 the command line would get a bit messy (in a ok, how do I quote this
 from this enviornment sort of way) - how common are ; characters as
 components of variable values?

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 their current semantics.


 
 Cheers,
 CY
 ___
 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
___
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


Re: [CMake] append command

2011-08-15 Thread Clifford Yapp
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 their current semantics.

nods Understood and agreed.  I had in the back of my mind a
CMAKE_POLICY CMP00## rule of some sort but that would be quite
disruptive...  the other approach that comes to mind would be to have
CMAKE_* variables accept a property of their own telling CMake whether
to treat them as space-separated strings or semi-colon separated lists
with defaults set to the current behavior (although would have the
advantage of not changing behaviors unless the build logic
specifically asked for a different behavior.)

Cheers,
CY
___
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


Re: [CMake] append command

2011-08-15 Thread Alexander Neundorf
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 ... CONCAT [SEP sep])
  
  equivalent to
  
  SET(variable ${variable}sepvalue...)
  
  I'm not sure this is actually necessary.
  Personally I'm fine with
  set(foo ${foo} bar)
  It's just one line. For properties more code is needed otherwise.
 
 So far, I also don't need such a string concatenation feature, but
 
 LIST(APPEND ...)
 
 and
 
 SET_PROPERTY(... APPEND/APPEND_STRING ...)
 
 aren't actually necessary, too, but convenient, so I would not be
 opposed to another convenience feature for concatenating strings.
 
  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.
  
  We can do that, if other people think also that this would be a better
  name. Or STRING_APPEND instead of APPEND_STRING ?
 
 The crucial point is that the subcommand/modifier for concatenating
 strings - regardless for which command(s) it is implemented - should
 
 - not be named APPEND because this term is already in use for lists,
   and there's at least one occasion where a list-related and a string-
   related += operation are about to coincide, namely SET_PROPERTY().
 - be named the same in all commands that provide - or possibly will
   provide - this functionality. SET_PROPERTY() is going to name it
   APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
   result in inconsistent CMakeLists.txt code if there'll be a SET()
   or STRING() implementation for concatenating strings: Certainly,
   one would not want to call the latter SET(... APPEND_STRING) or
   STRING(STRING_APPEND ...), so one ends up with two differently
   named subcommands/modifiers for the same kind of operation.
 
 For this reason, I'd recommend to reconsider the APPEND_STRING sub-
 command's naming and change it to a term that's also suitable for
 a string concatenation feature in other CMake commands - just to
 leave the door open. Therefor, my suggestion is CONCAT.

Anybody else has an opinion on this ?
I have no preferences among APPEND_STRING, STRING_APPEND and CONCAT.

Alex
___
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


Re: [CMake] append command

2011-08-15 Thread John Drescher
 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.

John
___
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


Re: [CMake] append command

2011-08-13 Thread Glenn Coombs
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 ?

--
Glenn


On 12 August 2011 05:16, Michael Hertling mhertl...@online.de 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 ... CONCAT [SEP sep])
 
  equivalent to
 
  SET(variable ${variable}sepvalue...)
 
  I'm not sure this is actually necessary.
  Personally I'm fine with
  set(foo ${foo} bar)
  It's just one line. For properties more code is needed otherwise.

 So far, I also don't need such a string concatenation feature, but

 LIST(APPEND ...)

 and

 SET_PROPERTY(... APPEND/APPEND_STRING ...)

 aren't actually necessary, too, but convenient, so I would not be
 opposed to another convenience feature for concatenating strings.

  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.
 
  We can do that, if other people think also that this would be a better
 name.
  Or STRING_APPEND instead of APPEND_STRING ?

 The crucial point is that the subcommand/modifier for concatenating
 strings - regardless for which command(s) it is implemented - should

 - not be named APPEND because this term is already in use for lists,
  and there's at least one occasion where a list-related and a string-
  related += operation are about to coincide, namely SET_PROPERTY().
 - be named the same in all commands that provide - or possibly will
  provide - this functionality. SET_PROPERTY() is going to name it
  APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
  result in inconsistent CMakeLists.txt code if there'll be a SET()
  or STRING() implementation for concatenating strings: Certainly,
  one would not want to call the latter SET(... APPEND_STRING) or
  STRING(STRING_APPEND ...), so one ends up with two differently
  named subcommands/modifiers for the same kind of operation.

 For this reason, I'd recommend to reconsider the APPEND_STRING sub-
 command's naming and change it to a term that's also suitable for
 a string concatenation feature in other CMake commands - just to
 leave the door open. Therefor, my suggestion is CONCAT.

 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

___
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

Re: [CMake] append command

2011-08-13 Thread Michael Wild
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 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 ?
 
 --
 Glenn
 
 
 On 12 August 2011 05:16, Michael Hertling mhertl...@online.de
 mailto:mhertl...@online.de 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 ... CONCAT [SEP sep])
 
  equivalent to
 
  SET(variable ${variable}sepvalue...)
 
  I'm not sure this is actually necessary.
  Personally I'm fine with
  set(foo ${foo} bar)
  It's just one line. For properties more code is needed otherwise.
 
 So far, I also don't need such a string concatenation feature, but
 
 LIST(APPEND ...)
 
 and
 
 SET_PROPERTY(... APPEND/APPEND_STRING ...)
 
 aren't actually necessary, too, but convenient, so I would not be
 opposed to another convenience feature for concatenating strings.
 
  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.
 
  We can do that, if other people think also that this would be a
 better name.
  Or STRING_APPEND instead of APPEND_STRING ?
 
 The crucial point is that the subcommand/modifier for concatenating
 strings - regardless for which command(s) it is implemented - should
 
 - not be named APPEND because this term is already in use for lists,
  and there's at least one occasion where a list-related and a string-
  related += operation are about to coincide, namely SET_PROPERTY().
 - be named the same in all commands that provide - or possibly will
  provide - this functionality. SET_PROPERTY() is going to name it
  APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
  result in inconsistent CMakeLists.txt code if there'll be a SET()
  or STRING() implementation for concatenating strings: Certainly,
  one would not want to call the latter SET(... APPEND_STRING) or
  STRING(STRING_APPEND ...), so one ends up with two differently
  named subcommands/modifiers for the same kind of operation.
 
 For this reason, I'd recommend to reconsider the APPEND_STRING sub-
 command's naming and change it to a term that's also suitable for
 a string concatenation feature in other CMake commands - just to
 leave the door open. Therefor, my suggestion is CONCAT.
 
 Regards,
 
 Michael

To be honest, the only occasion where I miss a more concise command is 
when I have pretty long variable names and it becomes essentially 
impossible to stay within a 80-columns line length limit.

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


Re: [CMake] append command

2011-08-13 Thread Glenn Coombs
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, Michael Wild them...@gmail.com wrote:


 To be honest, the only occasion where I miss a more concise command is
 when I have pretty long variable names and it becomes essentially
 impossible to stay within a 80-columns line length limit.

 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

___
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

Re: [CMake] append command

2011-08-13 Thread Clifford Yapp
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 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 ?

This surprised me as well - if you want to assemble a list of flags
on the fly (I needed to assemble lists of lists of flags - we pass a
lot of them) you have to take some care to either do the set trick
correctly or convert the list to a string at the end (if you can be
sure of where that is).

Do I understand correctly that the main concern is the ability to pass
args with ;' characters in these cases?  Then the question becomes
whether quoting ; characters as needed in user-specified options is
tricker than navigating the current behavior.  To be honest, I can see
where trying to specify an argument with a quoted ; character from
the command line would get a bit messy (in a ok, how do I quote this
from this enviornment sort of way) - how common are ; characters as
components of variable values?

Cheers,
CY
___
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


Re: [CMake] append command

2011-08-13 Thread Johan Björk
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 documentation about what happens when you pass in a list.

/Johan

On Sat, Aug 13, 2011 at 8: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
 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 ?

 This surprised me as well - if you want to assemble a list of flags
 on the fly (I needed to assemble lists of lists of flags - we pass a
 lot of them) you have to take some care to either do the set trick
 correctly or convert the list to a string at the end (if you can be
 sure of where that is).

 Do I understand correctly that the main concern is the ability to pass
 args with ;' characters in these cases?  Then the question becomes
 whether quoting ; characters as needed in user-specified options is
 tricker than navigating the current behavior.  To be honest, I can see
 where trying to specify an argument with a quoted ; character from
 the command line would get a bit messy (in a ok, how do I quote this
 from this enviornment sort of way) - how common are ; characters as
 components of variable values?

 Cheers,
 CY
 ___
 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

___
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

Re: [CMake] append command

2011-08-11 Thread Glenn Coombs
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 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).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
 software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __

___
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

Re: [CMake] append command

2011-08-11 Thread David Cole
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 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 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).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
 software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
 of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (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.
___
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

Re: [CMake] append command

2011-08-11 Thread Michael Wild
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 

Re: [CMake] append command

2011-08-11 Thread Alan W. Irwin

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 output_variable input [input...])

to make it similar to other string commands.

BUT if no input is given take it from ${output_variable} just as
for your suggestion.

I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands.  For those, I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands.  Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,

string(REGEX REPLACE regular_expression replace_expression output
variable)

so I believe this generalization would be backwards compatible.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
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


Re: [CMake] append command

2011-08-11 Thread Michael Hertling
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 

Re: [CMake] append command

2011-08-11 Thread Michael Wild
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 would generalize it as
 
 string(APPEND string output_variable input [input...])
 
 to make it similar to other string commands.
 
 BUT if no input is given take it from ${output_variable} just as
 for your suggestion.
 
 I would also make that same change for all other string commands of
 the same form, i.e., the various REGEX and REPLACE commands.  For those, I
 find the input string is often ${output_variable} so I believe this
 generalization would be a useful convenience for all users of those
 string subcommands.  Furthermore, even though this generalization of
 REGEX et all is a major change, IIRC you get a wrong number
 of arguments now for, e.g.,
 
 string(REGEX REPLACE regular_expression replace_expression output
 variable)
 
 so I believe this generalization would be backwards compatible.
 
 Alan

Making the string argument optional is not possible, since there is no
reliable way of determining whether it has been provided or not. Take

string(APPEND foo bar baz)

What is the intention here? Should the result be equivalent to

set(bar foobaz)

or

set(foo ${foo}barbaz)

?

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


Re: [CMake] append command

2011-08-11 Thread Michael Wild
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 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 

Re: [CMake] append command

2011-08-11 Thread Alexander Neundorf
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 necessary.
Personally I'm fine with 
set(foo ${foo} bar)
It's just one line. For properties more code is needed otherwise.

 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.

We can do that, if other people think also that this would be a better name.
Or STRING_APPEND instead of APPEND_STRING ?

Alex
___
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


Re: [CMake] append command

2011-08-11 Thread Alan W. Irwin

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 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 output_variable input [input...])

to make it similar to other string commands.

BUT if no input is given take it from ${output_variable} just as
for your suggestion.

I would also make that same change for all other string commands of
the same form, i.e., the various REGEX and REPLACE commands.  For those, I
find the input string is often ${output_variable} so I believe this
generalization would be a useful convenience for all users of those
string subcommands.  Furthermore, even though this generalization of
REGEX et all is a major change, IIRC you get a wrong number
of arguments now for, e.g.,

string(REGEX REPLACE regular_expression replace_expression output
variable)

so I believe this generalization would be backwards compatible.

Alan


Making the string argument optional is not possible


Please reread what I wrote above.  string is not optional.
It is input that would be optional.  And similarly for
REGEX and friends.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
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


Re: [CMake] append command

2011-08-11 Thread David Cole
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 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 output_variable input [input...])

 to make it similar to other string commands.

 BUT if no input is given take it from ${output_variable} just as
 for your suggestion.

 I would also make that same change for all other string commands of
 the same form, i.e., the various REGEX and REPLACE commands.  For those,
 I
 find the input string is often ${output_variable} so I believe this
 generalization would be a useful convenience for all users of those
 string subcommands.  Furthermore, even though this generalization of
 REGEX et all is a major change, IIRC you get a wrong number
 of arguments now for, e.g.,

 string(REGEX REPLACE regular_expression replace_expression output
 variable)

 so I believe this generalization would be backwards compatible.

 Alan


 Making the string argument optional is not possible


 Please reread what I wrote above.  string is not optional.
 It is input that would be optional.  And similarly for
 REGEX and friends.


 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
 software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __
 __**_
 Powered by www.kitware.com

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake



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 *and* input.

If we did have one, it would blend best with a signature like:

  string(CONCAT  /newStuff variable)

Although, I like CONCAT better than APPEND,  I still contend that the
best option so far is still to do nothing.
___
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

Re: [CMake] append command

2011-08-11 Thread David Cole
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 *and* input.


 Sorry I should have been more explicit.  The current signatures for
 REGEX et al are

 string(REGEX MATCH regular_expression
  output variable input [input...])
 string(REGEX MATCHALL regular_expression
   output variable input [input...])

 string(REGEX REPLACE regular_expression
   replace_expression output variable
   input [input...])
 string(REPLACE match_string
   replace_string output variable
   input [input...])

 What I am suggesting for all of them is to make input [input...])
 optional.  When that is not supplied, the input would be taken
 from ${output variable} instead.  And similarly for

 string(APPEND or CONCAT string output variable
   input [input...])

 Hope that makes clear what I am proposing.


 Alan
 __
 Alan W. Irwin

 Astronomical research affiliation with Department of Physics and Astronomy,
 University of Victoria (astrowww.phys.uvic.ca).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting
 software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __


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 the variable is
unexpectedly empty.

It may or may not be the same as the output variable... but I think it's a
good thing when you get a CMake error in such a case, as is the case now. I
hesitate to stop generating that error.

So I'm voting no on this proposal as well...
___
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

Re: [CMake] append command

2011-08-11 Thread Alan W. Irwin

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 the
variable is unexpectedly empty.

It may or may not be the same as the output variable... but I think it's a good 
thing when you get a CMake error in such a case, as is
the case now. I hesitate to stop generating that error.


I assumed the CMake logic parser could distinguish by a count of
arguments between the case where the last input argument was missing
(i.e. nothing specified by the user) as opposed to the cases you
mention where there is something there such as a dereferenced
non-existent variable or variable that is unexpectedly empty.
However, if the parser cannot distinguish the non-existent last
argument case from all others, then I would sadly have to agree with
your conclusion that my idea should be rejected.  Because I do agree
you want to continue to generate CMake errors for the cases you
mention.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
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


Re: [CMake] append command

2011-08-11 Thread Michael Hertling
On 08/11/2011 08:37 PM, Michael Wild wrote:
 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 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 

Re: [CMake] append command

2011-08-11 Thread Michael Hertling
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 ${variable}sepvalue...)
 
 I'm not sure this is actually necessary.
 Personally I'm fine with 
 set(foo ${foo} bar)
 It's just one line. For properties more code is needed otherwise.

So far, I also don't need such a string concatenation feature, but

LIST(APPEND ...)

and

SET_PROPERTY(... APPEND/APPEND_STRING ...)

aren't actually necessary, too, but convenient, so I would not be
opposed to another convenience feature for concatenating strings.

 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.
 
 We can do that, if other people think also that this would be a better name.
 Or STRING_APPEND instead of APPEND_STRING ?

The crucial point is that the subcommand/modifier for concatenating
strings - regardless for which command(s) it is implemented - should

- not be named APPEND because this term is already in use for lists,
  and there's at least one occasion where a list-related and a string-
  related += operation are about to coincide, namely SET_PROPERTY().
- be named the same in all commands that provide - or possibly will
  provide - this functionality. SET_PROPERTY() is going to name it
  APPEND_STRING, a longish and unfortunate misnomer, IMO, that will
  result in inconsistent CMakeLists.txt code if there'll be a SET()
  or STRING() implementation for concatenating strings: Certainly,
  one would not want to call the latter SET(... APPEND_STRING) or
  STRING(STRING_APPEND ...), so one ends up with two differently
  named subcommands/modifiers for the same kind of operation.

For this reason, I'd recommend to reconsider the APPEND_STRING sub-
command's naming and change it to a term that's also suitable for
a string concatenation feature in other CMake commands - just to
leave the door open. Therefor, my suggestion is CONCAT.

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


Re: [CMake] append command

2011-08-10 Thread David Cole
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:

     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).

 Programming affiliations with the FreeEOS equation-of-state implementation
 for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
 package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
 Linux Links project (loll.sf.net); and the Linux Brochure Project
 (lbproject.sf.net).
 __

 Linux-powered Science
 __


The APPEND_STRING arg was recently added to the CMake command
set_property, because of a similar complaint about the APPEND arg with
properties that are typically space separated.

I'm not sure if an APPEND_STRING arg belongs in the set command, though...

I understand that a line like this:

    set(CMAKE_EXE_LINKER_FLAGS_RELEASE
${CMAKE_EXE_LINKER_FLAGS_RELEASE} /INCREMENTAL:NO)

is visually too long because we use verbose variable naming, but it
is clear what it's doing, and it does work in all prior CMake
versions...

I tend toward keeping things as they are unless there's a strong
consensus that an addition like this would really improve things for
most CMake users.

Anybody else listening in here have an opinion?


Thanks,
David
___
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