[CMake] Unclear warning

[Alan W. Irwin]

On 2014-12-09 08:56+0100 Nils Gladitz wrote:

> On 12/09/2014 08:30 AM, Micha Renner wrote:
>> Hi,
>> 
>> what does this message mean?
>> 
>> The ASM_MASM compiler identification is MSVC
>> CMake Warning (dev) at C:/Program
>> Files/CMake/share/cmake-3.1/Modules/CMakeFindBinUtils.cmake:33 (if):
>>    Policy CMP0054 is not set: Only interpret if() arguments as variables
>> or
>> keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
>> details.  Use the cmake_policy command to set the policy and suppress
>> this
>>    warning.
>>
>>    Quoted variables like "MSVC" will no longer be dereferenced when the
>> policy
>>    is set to NEW.  Since the policy is not set the OLD behavior
>> will be used.
>> Call Stack (most recent call first):
>>    C:/Program
>> Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASMCompiler.cmake:137
>> (include)
>>    C:/Program
>> Files/CMake/share/cmake-3.1/Modules/CMakeDetermineASM_MASMCompiler.cmake:27 
>> (include)
>>    src/CMakeLists.txt:44 (ENABLE_LANGUAGE)
>> 
>> Is this a wanted warning?
>
> The warning is due to an ambiguity of if() argument evaluation in an internal 
> module (CMakeFindBinUtils.cmake).
>
> Assuming CMAKE_C_COMPILER_ID is MSVC and MSVC is 1 the following expression:
>  if("${CMAKE_C_COMPILER_ID}" STREQUAL "MSVC")
>
> With OLD CMP0054 behavior is basically the same as:
>  if(1 STREQUAL 1)
>
> with NEW CMP0054 policy behavior quoted arguments are protected from implicit 
> expansion so the same conditional boils down to:
>  if("MSVC" STREQUAL "MSVC")

Hi Nils:

I have never understood CMP0054 until now when I read your above
clear explanation.  So thanks very much for that!

My problem was the bad/ambiguous documentation of CMP0054 at
<http://www.cmake.org/cmake/help/v3.1/policy/CMP0054.html> which
states

"Only interpret if() arguments as variables or keywords when unquoted."

This wording implies (if taken rigourously) that

"${CMAKE_C_COMPILER_ID}"

is that exact literal string under NEW CMP0054 which I am sure (now
after reading your above explanation) was not
meant by the author of that documentation. Instead, of course,
${CMAKE_C_COMPILER_ID} always explicitly dereferences the variable
even if inside quotes.  I think this is all covered beautifully by
your above "protected from implicit expansion" wording.  So could you
please change
<http://www.cmake.org/cmake/help/v3.1/policy/CMP0054.html> to reflect
that much clearer wording?

>
> The warning was fixed in 
> http://www.cmake.org/gitweb?p=stage/cmake.git;a=commit;h=4d52cd36 .

This brings up the "ugly x" issue.

There, effectively

if(CMAKE_C_COMPILER_ID STREQUAL "MSVC")

is replaced by the extraordinarily ugly (in my opinion because it
reminds me of that sort of logic I used to see in shell scripts
configured by autotools [!])

if("x${CMAKE_C_COMPILER_ID}" STREQUAL "xMSVC")

According to your above explanation when CMAKE_C_COMPILER_ID
derefences to MSVC and MSVC dereferences to 1, this boils down to

if("x1" STREQUAL "x1")

for OLD CMP0054 and

if("xMSVC" STREQUAL "xMSVC")

for NEW CMP0054 (since MSVC will not implicitly dereference for NEW).  So this
style of logic will work regardless of whether the user is using OLD
CMP0054, NEW CMP0054 or even a a CMake version which does not define
CMP0054.

That's great, but could use of these ugly "x"'s, be accompanied by
the following comment?

# When OLD CMP0054 is no longer supported can drop the x.

Such self documentation of these ugly x's will avoid the situation
where users are inspired to propagate x's to user code (even if that
already assumes the latest CMake version with CMP0054 NEW).
Furthermore, such self-documentation insures these x's can all be
easily found and removed from the distributed
Modules/CMakeFindBinUtils.cmake when support for CMP0054 OLD gets
dropped from CMake (in the far distant feature).

In sum, I think a change to use much less ambiguous language
in <http://www.cmake.org/cmake/help/v3.1/policy/CMP0054.html> is
essential, and an extra line in distributed modules saying

# When OLD CMP0054 is no longer supported can drop the x.

is a "would be nice" wherever this ugly x logic is currently being deployed.

Alan

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________