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

Matthew Woehlke mw_triad at users.sourceforge.net
Fri Feb 21 16:17:37 EST 2014


On 2014-02-21 16:00, Ben Boeckel wrote:
> 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 :-).
>>
>> 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).

Even without a branch, I'll risk stating that requiring 'if(FOO)' to 
become 'if(${FOO})' is not likely to go over well :-). (If nothing else, 
I'll go ahead and object to such a change.) Probably implicit expansion 
should be allowed anywhere the user doesn't think of the arguments as 
strings, e.g. if(LESS), if(VERSION_LESS), etc., i.e. everything *except* 
the string and regex flavors.

>> (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.

The same validator could also reject e.g. "TRUE" :-).

-- 
Matthew




More information about the cmake-developers mailing list