On Thu, Aug 11, 2011 at 5:28 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca>wrote:
> 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
