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 

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

Follow this link to subscribe/unsubscribe:

Reply via email to