[CMake] Explanation....

Johannes Zarl johannes.zarl at jku.at
Mon Apr 28 04:58:37 EDT 2014


On Thursday, 24. April 2014, 17:34:40, Matthew Woehlke wrote:
> On 2014-04-24 04:53, Johannes Zarl wrote:
> > On Wednesday, 23. April 2014, 18:54:39, Matthew Woehlke wrote:
> >>> if (" ${arg}" STREQUAL " TOTO")
> >> 
> >> set(" TOTO" "evil")
> > 
> > You sure? When I checked, this did not work.
> 
> Are *you* sure? :-)

Yes, I am. For the specific use-case given in this thread (the STREQUAL), the 
prefix *is* safe to use. I still prefer the MATCHES syntax, as it is not too 
much overhead and prods the programmer to think about why it was used and what 
is happening.

And of course, David Cole is totally right when he says:

>> It's just ridiculous to waste time trying to justify the existing
>> behavior. It's more confusing than useful, and ought to be changed.


> Right; *explicit* expansion is limited in what characters are allowed.
> As David Cole points out, you must expand such variables indirectly. Of
> course, implicit expansion counts as indirect expansion, which is why
> there is no safe character/prefix that can guarantee implicit expansion
> won't occur.

I'm always happy to learn something new. How would you manage to make the 
following if statement trigger?

set( arg "value")
if (" ${arg}" STREQUAL " TOTO" )
  message ( "arg equals 'TOTO', and arg equals 'value'" )
endif()


> (And - again as David Cole already noted - you didn't get an error in
> the set() command, did you?)

No, but the if statement didn't trigger, either.


> On 2014-04-24 06:31, David Cole wrote:
> > I, for one, would fully support breaking backwards compatibility to fix
> > this, and be strict with variable and macro and function name
> > identifiers.
> 
> Of course, the *real* problem is implicit expansion. The permissiveness
> of variable naming makes it harder to work around this, but would be
> less of an issue if implicit expansion was less "eager".

I aggree 100% with both of you, here.

Cheers,
  Johannes


More information about the CMake mailing list