[CMake] append command

[David Cole]

On Thu, Aug 11, 2011 at 5:28 PM, Alan W. Irwin <irwin at 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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110811/8623b62d/attachment-0001.htm>