MantisBT - CMake
View Issue Details
0004249CMakeCMakepublic2006-12-30 00:062015-07-08 08:57
Todd Rovito 
Bill Hoffman 
lowfeaturealways
closednot fixable 
 
 
0004249: Generate a warning when a undefined Cmake variable is used
If a CMakeLists.txt file contains the following:

If (UNIX)
    set(VARIABLE_NAME SomeFile.h SomeFile.cxx)

    add_executable(ProgramName SomeFileMain.cxx ${VARIABLE_NAME_UNDEFINED})

Endif (UNIX)

# end of CMakeLists.txt file

Cmake will not complain about VARIABLE_NAME_UNDEFINED being undefined it still tries to build the project. If possible I would like cmake to print a warning that it is using an undefined variable.
No tags attached.
diff undefined_variable_warnings.diff (21,243) 2008-03-01 14:34
https://public.kitware.com/Bug/file/1333/undefined_variable_warnings.diff
txt CMakeLists.txt (429) 2008-03-01 14:35
https://public.kitware.com/Bug/file/1334/CMakeLists.txt
Issue History
2008-03-01 14:32Philip LowmanNote Added: 0010678
2008-03-01 14:34Philip LowmanFile Added: undefined_variable_warnings.diff
2008-03-01 14:35Philip LowmanFile Added: CMakeLists.txt
2015-02-26 14:08Stephen KellyNote Added: 0038083
2015-02-26 14:08Stephen KellyStatusassigned => resolved
2015-02-26 14:08Stephen KellyResolutionopen => not fixable
2015-07-08 08:57Robert MaynardNote Added: 0039072
2015-07-08 08:57Robert MaynardStatusresolved => closed

Notes
(0006063)
Alex Neundorf   
2007-01-02 12:24   
That's similar to how all other scripting languages I know work.
(0010678)
Philip Lowman   
2008-03-01 14:32   
Here's a patch for implementing this (although it needs testing in Windows and on other platforms to squash any remaining internal CMake-generated warnings).

I modified cmCommandArgumentParserHelper.cxx so that when variables are expanded a warning is issued if the variable does not exist. This behavior can be overridden in two ways:

  1. The user may set CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS which will suppress all warnings (this variable would presumably be set by CMAKE_BACKWARDS_COMPATABILITY)

  2. The user may dereference variables with a special key (right now it's ALLOWUNDEF) to indicate that they are ok with the idea that the variable may be undefined and that no warning need be emitted.
     SET(foo $ALLOWUNDEF{bar})

There are several core CMake core modules that are designed to use variables that are often left undefined. An example is CMakeCommonLanguageInclude.cmake which optionally uses a lot of "_INIT" type variables to populate the cache. Instead of wrapping all of these cache assignments with annoying conditionals the $ALLOWUNDEF keyword was added here.

Assuming that this is a feature that is still desired, some work would remain:

1. Trying out initial CMake configuration on a variety of platforms, hunting down warnings and either fixing the code not to dereference undefined variables or adding the ALLOWUNDEF keyword.

2. Having a look at the standard CMake modules and either add checks for the existence of external variables before dereferencing them or add the ALLOWUNDEF keyword.

3. Make the CMAKE_BACKWARDS_COMPATABILITY variable define CMAKE_ALLOW_UNKNOWN_VARIABLE_READ_ACCESS for <= 2.4

4. Add documentation on $ALLOWUNDEF{} somewhere
(0038083)
Stephen Kelly   
2015-02-26 14:08   
This isn't going to happen. Might as well close it.
(0039072)
Robert Maynard   
2015-07-08 08:57   
Closing resolved issues that have not been updated in more than 4 months.