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