Re: [CMake] append command
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[CMake] append command
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
