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

[Ben Boeckel]

On Fri, Feb 21, 2014 at 14:18:02 -0500, Jean-Christophe Fillion-Robin wrote:
> On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel <ben.boeckel at kitware.com>wrote:
> > I agree in general, however, my CMake style is to quote all variable
> > expansions unless I want argument splitting. This rule would break code
> > like this:
> >
> >     if ("CMAKE_${LANG}_FLAGS")
> >     endif ()
> >
> > which would be unfortunate, IMO.
> 
> As a quick check, I ran the following search on CMake code base and it
> returns nothing:
> 
>    cd ./CMake-src
>    ack --cmake "\(\s*\"[a-zA-Z0-9]+\$"
> 
> Also nothing for Slicer, ITKv4, VTK6, ...

Yeah, I don't expect it to be common.

As a more extensive check, the following gives no results in ParaView,
VTK, or VXL which one would expect the name quoted string to be treated
as a variable name:

    git grep 'if\s*(' -- '*.cmake' '**/CMakeLists.txt' | \
        grep --color=yes -e '"\([^$ ][^"]\+\)\?"'

It does miss multi-line if statements though.

> If possible, not having implicit expansion for quoted argument would be
> great at make things more intuitive and practical.

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? I agree that the quoted rule
would be nice, but it would require passing quoted-ness flags along with
the arguments themselves to the commands which would require an API
change (or a forwarding overload with a good default implementation) to
the cmCommand base class.

Another thing which I've run across is:

    if (TRUE)
    endif ()

doesn't try to look up ${TRUE} (which I 100% agree with), but it means
that variables named 'TRUE' (and any other string for which IsOn and
IsOff returns 'true' for) act differently than variables with other
names.

--Ben