MantisBT - CMake
View Issue Details
0011725CMakeCMakepublic2011-01-19 17:032011-01-31 16:09
Daniel Richard G. 
Brad King 
normalminoralways
closedfixed 
CMake 2.8.3 
CMake 2.8.4CMake 2.8.4 
0011725: CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified
At the top of my top-level CMakeLists.txt file, I have

    SET(CMAKE_USER_MAKE_RULES_OVERRIDE CMakeCommon.txt)

My CMakeCommon.txt file lives right alongside the aforementioned listfile, and things worked dandily like this for the last few years (up to 2.8.1).

With 2.8.3, however, I get this:

********(cut here)********
-- The C compiler identification is Intel
-- Using predefined Intel compiler flags
-- Check for working C compiler: C:/Program Files (x86)/Intel/Compiler/C++/9.1/EM64T/Bin/icl.exe
CMake Error at X:/freeport/arch/win64_icl_mt/share/cmake-2.8/Modules/CMakeCInformation.cmake:79 (INCLUDE):
  include could not find load file:

    CMakeCommon.txt
Call Stack (most recent call first):
  CMakeLists.txt:3 (PROJECT)
********(cut here)********

Things work again if I edit the line to

    SET(CMAKE_USER_MAKE_RULES_OVERRIDE ${CMAKE_SOURCE_DIR}/CMakeCommon.txt)

However, I believe the previous behavior was reasonable, where this variable would implicitly be interpreted relative to ${CMAKE_SOURCE_DIR} rather than anywhere else.
No tags attached.
related to 0010902closed Brad King USER_MAKE_RULES_OVERRIDE variable is not used in initial try_compile 
related to 0011724closed Brad King CMAKE_RUNTIME_OUTPUT_DIRECTORY breaks try_compile()'s COPY_FILE directive in 2.8.3 
related to 0011942closed David Cole INCLUDE inside file defined by CMAKE_USER_MAKE_RULES_OVERRIDE broken since 2.8.3 
Issue History
2011-01-19 17:03Daniel Richard G.New Issue
2011-01-19 17:37Bill HoffmanNote Added: 0024937
2011-01-19 17:41Brad KingAssigned To => Brad King
2011-01-19 17:41Brad KingStatusnew => assigned
2011-01-19 17:41Brad KingNote Added: 0024940
2011-01-19 17:47Brad KingRelationship addedrelated to 0010902
2011-01-19 17:48Brad KingRelationship addedrelated to 0011724
2011-01-19 17:51Brad KingNote Added: 0024942
2011-01-19 17:52Brad KingNote Added: 0024943
2011-01-19 18:39Daniel Richard G.Note Added: 0024947
2011-01-19 18:44Daniel Richard G.Note Edited: 0024947bug_revision_view_page.php?bugnote_id=24947#r143
2011-01-20 07:49Brad KingTarget Version => CMake 2.8.4
2011-01-20 07:51Brad KingNote Added: 0024950
2011-01-20 07:51Brad KingStatusassigned => closed
2011-01-20 07:51Brad KingResolutionopen => fixed
2011-01-31 16:09David ColeFixed in Version => CMake 2.8.4
2011-03-31 12:35Brad KingRelationship addedrelated to 0011942

Notes
(0024937)
Bill Hoffman   
2011-01-19 17:37   
What do you get with 2.8.4 RC?
(0024940)
Brad King   
2011-01-19 17:41   
Out of curiosity, what do you set in your CMakeCommon.txt?
(0024942)
Brad King   
2011-01-19 17:51   
Both this and issue 0011724 were introduced by this commit:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=295b5b60 [^]

which was created in response to issue 0010902.
(0024943)
Brad King   
2011-01-19 17:52   
The issue still exists in 2.8.4-rc1.
(0024947)
Daniel Richard G.   
2011-01-19 18:39   
(edited on: 2011-01-19 18:44)
CMakeCommon.txt is used primarily to set CMAKE_C_FLAGS_INIT and friends, although a number of other general CMake configuration variables are set in there as well (like CMAKE_RUNTIME_OUTPUT_DIRECTORY, CMAKE_INCLUDE_CURRENT_DIR, etc.).

Looking at the commit, what would seem to be needed is (1) to qualify relative paths in the OVERRIDE variable w.r.t. ${CMAKE_SOURCE_DIR}, making explicit what had been implicit before, and (2) to make COPY_FILE aware of CMAKE_RUNTIME_OUTPUT_DIRECTORY, to address issue 11724.

(0024950)
Brad King   
2011-01-20 07:51   
I've committed a change that converts CMAKE_USER_MAKE_RULES_OVERRIDE and friends to a full path as soon as they are used (and before any try_compile-s occur):

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a146e034 [^]

That way the full paths will be passed down to try_compile projects.