[cmake-developers] New EVIS parser moving forward (3.1)

Ben Boeckel ben.boeckel at kitware.com
Fri Feb 21 16:00:08 EST 2014


On Fri, Feb 21, 2014 at 15:34:44 -0500, Matthew Woehlke wrote:
> On 2014-02-21 14:51, Ben Boeckel wrote:
> >If I made a branch which warned when implicit expansion was done, would
> >folks be willing to run it over various codebases to see how annoying it
> >would be to just remove it altogether?
> 
> To be clear, are we talking about in the case of e.g. STREQUAL, or
> *ever*? Because I'm sure breaking 'if(Pkg_FOUND)' would be very, very
> bad :-).

My thought was "ever", but for direct variable tests we could support
implicit dereference. We'd have to document that testing the variable
"TRUE" requires a dereference though (or we could just ban variables
with names for which either IsOn or IsOff returns 'true' altogether
since that is where if() skips the dereference).

> I'd be a little suspicious of even the former; I know at least in my
> case, greater understanding of implicit expansion leads to greater
> *reliance* on it as a guard against unintended expansion (i.e. 'if
> (FOO STREQUAL "...")' instead of 'if ("${FOO}" STREQUAL "...")').

Agreed. Which is why I'd like to know how much code would actually need
to change (since upgrading code to use the new policy would make older
CMake versions do the wrong thing since they'll dereference the value
now). Would it be out of the question to allow the policy to *only* be
via the cmake_minimum_required() call and not manually to avoid such
issues?

> (Loosely related: if variable names were sane, it would at least be
> safe to write e.g. 'if ("#${FOO}" STREQUAL "#...")'. But alas,
> '#${FOO}' might still be the name of a variable.)

You could probably stick some sort of validator in front of the variable
map storage. I'd recommend also doing it on queries as an AUTHOR_WARNING
as well.

--Ben



More information about the cmake-developers mailing list