[CMake] non-set-able variables

Voisard, Shane S CIV NSWCDD, K54 christopher.voisard at navy.mil
Tue Nov 24 17:15:19 EST 2009


I made my parent script cd into my "binary_dir", execute (the command-line) cmake from there and all is well ..... except for another set command (in the top-level CMakeLists.txt) that is no longer effective:

set (CMAKE_CONFIGURATION_TYPES "Release" CACHE STRING "" FORCE)

I tried this alternative, with no effect, based upon online 2.6 documentation:

set (CMAKE_CONFIGURATION_TYPES "Release" CACHE INTERNAL "" FORCE)

Previously, when I ran cmake-gui.exe, setting this variable caused cmake to generate visual studio vcproj files with only the 'release' configuration.  But the command-line cmake does not create this output in spite of this set command.

I will hazard a guess that this is another cmake variable (including CMAKE_BINARY_DIR & others) that is set-able in the GUI, before the 1st configuration, but not set-able in the command-line cmake ?

Upon reflection, I think there is a major issue here:
1) Online documentation does not categorize set-able vs. non-set-able variables.
2) cmake-gui variable-setting behavior differs significantly from cmake-cmdline variable-setting behavior.
3) most importantly -- my efforts to debug via message() output did not help me to clarify this situation.  I output these cmake variables' values before and after setting them, cmake reported these values had changed, but the values did not take effect.
 
Currently, there is no way for me to know that cmake ignores these set commands.   A fix could be:
1) cmake reports "warning: readonly variable $(CMAKE_FOO) cannot be set" 
2) message() reports  only the *effective* value of variables, indicating that such set commands are ignored.
3) the online documentation could categorize the variables and state their set-ability with respect to cmake-gui and cmake-cmdline.

I went back and searched the cmake FAQ and the cmake bugtracker postings regarding 'variable(s)' and 'set(ting)', but I didn't find an question / issue  like this one.

Shane Voisard


More information about the CMake mailing list