[cmake-developers] if() auto-dereference (was: Roadmap to CMake 3.0)

Brad King brad.king at kitware.com
Mon Oct 21 14:03:52 EDT 2013


On 10/21/2013 01:36 PM, Alexander Neundorf wrote:
> Would this also be a chance to change the if( STREQUAL ) string vs. variable 
> lookup rules ?
> Hmm, simply changing the behaviour would most probably break a lot of stuff.
> Maybe with a policy ?
> I.e. never do variable lookup, always just compare the strings

The current behavior is too in-grained to drop auto-dereference outright.
At most I would consider making it conditional on the argument quoting
as I proposed here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6377/focus=6379

For example:

 if(maybevar STREQUAL "value")

will dereference the variable but

 if("maybevar" STREQUAL "value")

would not.  That way one could ensure no auto-dereference by always
quoting both sides, which is good practice anyway.  We need
auto-dereference for the common

 if(SOME_VARIABLE)

to continue working.

This would have to be done with a policy whose warning triggers only when
the output of a conditional will be different.  It will also require
some internal changes in the way CMake tracks command arguments because
if() will now need to know how an argument was quoted.

Side note: As soon as CMP0028 is in master I have CMP0029 through
CMP0036 ready to disallow a bunch of old commands, so don't try
implementing this with a policy number below CMP0037.

As for a place in the roadmap, I think the list of major changes
for 3.0 is already enough to ask users to understand, and the proposed
policy may trigger a *lot* of warnings.  Since this will be done with a
policy it can be done at any time.

> Or introduce the whole set of comparison operators ("==", "<", etc.), which 
> would then never do variable lookup, and "deprecate" the current ones ?

That was discussed and IIRC rejected in the above-linked thread.
The operators are simply not informative enough about how the
comparison is to be done.

-Brad



More information about the cmake-developers mailing list