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>}<sep><value>...")
> 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




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.

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.


Powered by www.kitware.com

Visit other Kitware open-source projects at 

Please keep messages on-topic and check the CMake FAQ at: 

Follow this link to subscribe/unsubscribe:

Reply via email to