On Thu, Aug 11, 2011 at 4:31 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>wrote:
> 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<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<http://www.cmake.org/Wiki/CMake_FAQ>
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/**listinfo/cmake<http://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
