MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008453CMakeCMakepublic2009-02-02 14:192016-06-10 14:30
ReporterDaniel Richard G. 
Assigned ToBill Hoffman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008453: Cannot set CMAKE_C_COMPILER_INIT in CMAKE_USER_MAKE_RULES_OVERRIDE file
DescriptionI have multiple projects making use of CMake. Each of these loads a file with common definitions by setting CMAKE_USER_MAKE_RULES_OVERRIDE before the first call to PROJECT() in the top-level CMakeLists.txt file.

One of the variables that this file sets is CMAKE_C_COMPILER_INIT. In my Windows (NMake Makefiles) build environment, both cl.exe and icl.exe are available, and an environment variable is used to determine which of these two should be used. (NOTE: I am aware of the CC environment variable; it is not an option given the build rig I am using.)

However, setting CMAKE_C_COMPILER_INIT in the override file has no effect, even with CACHE/FORCE. In order to make the assignment work, I have to set the variable in the top-level CMakeLists.txt file (also before the first PROJECT() call).
Steps To Reproduce
Additional InformationThe first few lines from one of my top-level CMakeLists.txt files, just to make things a little more concrete...

----begin----
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.2)

SET(CMAKE_USER_MAKE_RULES_OVERRIDE CMakeCommon.txt)

# This bit should be in CMakeCommon.txt, but it doesn't work there :P
#
IF($ENV{TG_ARCH} MATCHES "^win.*_icl")
    SET(CMAKE_C_COMPILER_INIT icl)
ENDIF($ENV{TG_ARCH} MATCHES "^win.*_icl")

PROJECT(TGExt)
----end----
TagsNo tags attached.
Relationships
Attached Filestxt CMakeLists.txt (326) 2009-02-02 15:13
https://public.kitware.com/Bug/file/2027/CMakeLists.txt
txt CMakeCommon.txt (64) 2009-02-02 15:13
https://public.kitware.com/Bug/file/2028/CMakeCommon.txt
txt cmake-log-1.txt (95,157) 2009-02-02 15:13
https://public.kitware.com/Bug/file/2029/cmake-log-1.txt
txt cmake-log-2.txt (124,939) 2009-02-02 15:13
https://public.kitware.com/Bug/file/2030/cmake-log-2.txt
Issue History
Date ModifiedUsernameFieldChange
2009-02-02 14:19Daniel Richard G.New Issue
2009-02-02 14:44Bill HoffmanNote Added: 0014751
2009-02-02 14:44Bill HoffmanStatusnew => assigned
2009-02-02 14:44Bill HoffmanAssigned To => Bill Hoffman
2009-02-02 15:12Daniel Richard G.Note Added: 0014752
2009-02-02 15:13Daniel Richard G.File Added: CMakeLists.txt
2009-02-02 15:13Daniel Richard G.File Added: CMakeCommon.txt
2009-02-02 15:13Daniel Richard G.File Added: cmake-log-1.txt
2009-02-02 15:13Daniel Richard G.File Added: cmake-log-2.txt
2009-02-02 15:34Bill HoffmanNote Added: 0014754
2009-02-02 16:24Daniel Richard G.Note Added: 0014756
2009-02-02 17:48Bill HoffmanNote Added: 0014758
2009-02-08 18:00Daniel Richard G.Note Added: 0014837
2016-06-10 14:27Kitware RobotNote Added: 0041497
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0014751)
Bill Hoffman   
2009-02-02 14:44   
Can you run cmake --trace, and post the output as an attachment? Also, what version of cmake are you having trouble with?
(0014752)
Daniel Richard G.   
2009-02-02 15:12   
This is all wrt CMake 2.6.2.

I've put together a small test case, built from the Hello example in the CMake source tree. I'll upload four files:

1. The modified Hello CMakeLists.txt file

2. A trivial CMakeCommon.txt that sets CMAKE_{C,CXX}_COMPILER_INIT

3. A --trace log from the example, where *_COMPILER_INIT is set in the override file

4. A --trace log from the example, where *_COMPILER_INIT is set in the listfile

(Note: CMake did not configure correctly in either trace run, due to a less-than-straightforward setup of compilers and SDKs on my system. However, you can see that in the first log, MSVC's cl.exe is (erroneously) selected, and in the second log, Intel's icl.exe is used.
(0014754)
Bill Hoffman   
2009-02-02 15:34   
OK, this may not be possible... It is generally not possible to change the compiler for CMake once it has picked one. The rule over ride stuff was meant to change things like CMAKE_CXX_FLAGS. The way to change the compiler is with CC or CXX, which you say you can not use... So, it is not a bug, but a missing feature.
(0014756)
Daniel Richard G.   
2009-02-02 16:24   
This general issue of which variables are set when and where has been one of the more frustrating aspects of using CMake.

I think I get what you're saying... that when the override file is read in, the compiler has already been chosen. It should be possible to set different values of e.g. CMAKE_CXX_FLAGS_INIT based on that, so this isn't necessarily a behavior that should change.

Is CMAKE_{C,CXX}_COMPILER_INIT a supported variable? Should I add a note describing this particular caveat to the wiki?
(0014758)
Bill Hoffman   
2009-02-02 17:48   
The bootstrapping part of CMake where it sets initial values of variables and picks compilers is a tricky part. However, you are going outside the intended API a bit, as we expect people to use CC and CXX, and you are using TG_ARCH. In general, once CMake picks a compiler it is too late to change it. You can influence the compiler that is picked with the CMAKE_{C,CXX}_COMPILER_INIT if it is set before the project command or an enable_language command. So, CMAKE_USER_MAKE_RULES_OVERRIDE wiki entries should be clear that they can not be used to pick the compiler, as the compiler has already been picked.
(0014837)
Daniel Richard G.   
2009-02-08 18:00   
I've added notes to the "CMake FAQ" and "CMake Useful Variables" pages on the wiki. The caveat for CMAKE_USER_MAKE_RULES_OVERRIDE is already (implicitly) covered on the "CMake 2.6.2 Docs" page: "If this variable is set, it should to point to a CMakeLists.txt file that will be read in by CMake after all the system settings have been set, but before they have been used." I'm not sure if there is more that can or should be said for that.

Please review my edits to the wiki, and if everything looks good, I think this issue can be closed.
(0041497)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.