MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0011942CMakeCMakepublic2011-03-09 03:122011-10-03 09:54
ReporterMartin Apel 
Assigned ToDavid Cole 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
Platformx86OSLinux and WindowsOS Version
Product VersionCMake 2.8.3 
Target VersionCMake 2.8.5Fixed in VersionCMake 2.8.5 
Summary0011942: INCLUDE inside file defined by CMAKE_USER_MAKE_RULES_OVERRIDE broken since 2.8.3
DescriptionWe use a file for overriding the CMAKE_*_INIT variable, which is set via CMAKE_USER_MAKE_RULES_OVERRIDE. This file includes another file via include, which is located in the same directory.

Up to 2.8.2 this worked fine, but since 2.8.3 the referenced file
is not found anymore. It doesn't matter, if the referenced file is referenced via ${CMAKE_SOURCE_DIR}, ${CMAKE_CURRENT_SOURCE_DIR} or as a relative path name.

Using trace mode shows, that during try_compile the file is not found anymore,
because CMAKE_SOURCE_DIR and CMAKE_CURRENT_SOURCE_DIR seem to be modified.
Steps To ReproduceCreate the setup described above:
- A simple main CMakeLists.txt, which sets CMAKE_USER_MAKE_RULES_OVERRIDE to file a
- File a, which contains an INCLUDE statement to file b, located in the same directory
- File b, which may contain nothing
Additional InformationThis is probably caused by the implementation of feature request 0010902.
TagsNo tags attached.
Relationships
related to 0010902closed Brad King USER_MAKE_RULES_OVERRIDE variable is not used in initial try_compile 
related to 0011725closed Brad King CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified 
related to 0011469closed Brad King CMAKE_USER_MAKE_RULES_OVERRIDE with system checks goes into recursion and aborts 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-03-09 03:12Martin ApelNew Issue
2011-03-09 04:01Rolf Eike BeerNote Added: 0025698
2011-03-09 04:29Martin ApelNote Added: 0025699
2011-03-31 12:35Brad KingRelationship addedrelated to 0010902
2011-03-31 12:35Brad KingRelationship addedrelated to 0011725
2011-03-31 12:36Brad KingRelationship addedrelated to 0011469
2011-03-31 12:43Brad KingNote Added: 0025985
2011-03-31 12:46Brad KingAssigned To => Brad King
2011-03-31 12:46Brad KingStatusnew => assigned
2011-03-31 12:51Brad KingNote Added: 0025986
2011-03-31 12:52Brad KingNote Added: 0025987
2011-03-31 12:55Brad KingNote Edited: 0025987bug_revision_view_page.php?bugnote_id=25987#r273
2011-04-01 03:47Martin ApelNote Added: 0026004
2011-04-01 08:27Brad KingNote Added: 0026005
2011-04-14 14:40David ColeTarget Version => CMake 2.8.5
2011-05-25 17:11David ColeAssigned ToBrad King => David Cole
2011-05-25 17:15David ColeNote Added: 0026598
2011-05-25 17:15David ColeStatusassigned => resolved
2011-05-25 17:15David ColeFixed in Version => CMake 2.8.5
2011-05-25 17:15David ColeResolutionopen => no change required
2011-10-03 09:54David ColeNote Added: 0027508
2011-10-03 09:54David ColeStatusresolved => closed

Notes
(0025698)
Rolf Eike Beer   
2011-03-09 04:01   
Have you tried using CMAKE_CURRENT_LIST_DIR (introduced in 2.8.3)?
(0025699)
Martin Apel   
2011-03-09 04:29   
Thanks for your quick reply. I just tried this, and CMake seems to find the files this way. But unfortunately CMake does not recognize variables set in the surrounding CMakeLists.txt inside these included files anymore, so it is still not usable for our case.
I tried this with 2.8.3 and 2.8.4.
(0025985)
Brad King   
2011-03-31 12:43   
Here is some history.

Original change that led to all these problems by including the file inside try_compiles:

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

It was correct according to the intended use case, now documented:

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

Later it was made more robust inside try_compiles:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5792d3a3 [^]
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c83a834d [^]
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a146e034 [^]
(0025986)
Brad King   
2011-03-31 12:51   
Prior to the fix for issue 0010902 the CMAKE_USER_MAKE_RULES_OVERRIDE variable was completely ignored during try_compiles. Your code was silently failing to do checks representative of the flags in use for the build.

> Using trace mode shows, that during try_compile the file is not found anymore,
> because CMAKE_SOURCE_DIR and CMAKE_CURRENT_SOURCE_DIR seem to be modified.

They are not modified. They have the same value as before...the location of the source tree being compiled. The difference is that now the override file is loaded both during the main project() command that enables languages and then again inside each try_compile.
You need to make your override file capable of running inside each try_compile.
(0025987)
Brad King   
2011-03-31 12:52   
(edited on: 2011-03-31 12:55)
This variable has always been an obscure last-resort kind of feature. When written the intention was that the file loaded might contain nothing more complex than
  set(CMAKE_EXE_LINKER_FLAGS_INIT -myflag)

For this intended use case the fix of 0010902 was correct.
(0026004)
Martin Apel   
2011-04-01 03:47   
Does that mean that usage of the INCLUDE directive is illegal in a file used by CMAKE_USER_MAKE_RULES_OVERRIDE?
(0026005)
Brad King   
2011-04-01 08:27   
No, I was just explaining what the thinking was behind the feature originally and why changes in behavior like that for 0010902 were not considered drastic.

The reason including by CMAKE_SOURCE_DIR and CMAKE_CURRENT_SOURCE_DIR do not seem to work is because they *do* work when the language is initially enabled in the outer project but then do not work inside try-compiles. You can use ${CMAKE_CURRENT_LIST_DIR} with CMake 2.8.3 or later. In any version you can use get_filename_component() to extract the directory part out of CMAKE_CURRENT_LIST_FILE.

If you want to do non-trivial flag initialization I suggest this:

project(MyProj NONE) # enables no languages yet

include(ComplicatedFlagInitLogicInAsManyFilesAsYouWant)

# Create a file configured with all the right stuff hard-coded.
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/overrides.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/overrides.cmake)
set(CMAKE_USER_MAKE_RULES_OVERRIDE ${CMAKE_CURRENT_BINARY_DIR}/overrides.cmake)

enable_language(C)
enable_language(CXX)
(0026598)
David Cole   
2011-05-25 17:15   
No change is required in CMake to resolve this issue. Please adapt your project's code, if necessary...
(0027508)
David Cole   
2011-10-03 09:54   
Closing resolved issues that have not been updated in more than 4 months.