[cmake-developers] [CMake 0011725]: CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified

Mantis Bug Tracker mantis at public.kitware.com
Wed Jan 19 17:03:51 EST 2011


The following issue has been SUBMITTED. 
====================================================================== 
http://public.kitware.com/Bug/view.php?id=11725 
====================================================================== 
Reported By:                Daniel R. Gomez
Assigned To:                
====================================================================== 
Project:                    CMake
Issue ID:                   11725
Category:                   CMake
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2011-01-19 17:03 EST
Last Modified:              2011-01-19 17:03 EST
====================================================================== 
Summary:                    CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works
if unqualified
Description: 
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.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-19 17:03 Daniel R. GomezNew Issue                                    
======================================================================




More information about the cmake-developers mailing list