View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011942CMakeCMakepublic2011-03-09 03:122011-10-03 09:54
ReporterMartin Apel 
Assigned ToDavid Cole 
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.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to 0010902closedBrad King USER_MAKE_RULES_OVERRIDE variable is not used in initial try_compile 
related to 0011725closedBrad King CMAKE_USER_MAKE_RULES_OVERRIDE path no longer works if unqualified 
related to 0011469closedBrad King CMAKE_USER_MAKE_RULES_OVERRIDE with system checks goes into recursion and aborts 

-  Notes
Rolf Eike Beer (developer)
2011-03-09 04:01

Have you tried using CMAKE_CURRENT_LIST_DIR (introduced in 2.8.3)?
Martin Apel (reporter)
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.
Brad King (manager)
2011-03-31 12:43

Here is some history.

Original change that led to all these problems by including the file inside try_compiles:;a=commitdiff;h=295b5b60 [^]

It was correct according to the intended use case, now documented:;a=commitdiff;h=a5300f1d [^]

Later it was made more robust inside try_compiles:;a=commitdiff;h=5792d3a3 [^];a=commitdiff;h=c83a834d [^];a=commitdiff;h=a146e034 [^]
Brad King (manager)
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.
Brad King (manager)
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

For this intended use case the fix of 0010902 was correct.

Martin Apel (reporter)
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?
Brad King (manager)
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


# Create a file configured with all the right stuff hard-coded.

David Cole (manager)
2011-05-25 17:15

No change is required in CMake to resolve this issue. Please adapt your project's code, if necessary...
David Cole (manager)
2011-10-03 09:54

Closing resolved issues that have not been updated in more than 4 months.

- Issue History
Date Modified Username Field Change
2011-03-09 03:12 Martin Apel New Issue
2011-03-09 04:01 Rolf Eike Beer Note Added: 0025698
2011-03-09 04:29 Martin Apel Note Added: 0025699
2011-03-31 12:35 Brad King Relationship added related to 0010902
2011-03-31 12:35 Brad King Relationship added related to 0011725
2011-03-31 12:36 Brad King Relationship added related to 0011469
2011-03-31 12:43 Brad King Note Added: 0025985
2011-03-31 12:46 Brad King Assigned To => Brad King
2011-03-31 12:46 Brad King Status new => assigned
2011-03-31 12:51 Brad King Note Added: 0025986
2011-03-31 12:52 Brad King Note Added: 0025987
2011-03-31 12:55 Brad King Note Edited: 0025987 View Revisions
2011-04-01 03:47 Martin Apel Note Added: 0026004
2011-04-01 08:27 Brad King Note Added: 0026005
2011-04-14 14:40 David Cole Target Version => CMake 2.8.5
2011-05-25 17:11 David Cole Assigned To Brad King => David Cole
2011-05-25 17:15 David Cole Note Added: 0026598
2011-05-25 17:15 David Cole Status assigned => resolved
2011-05-25 17:15 David Cole Fixed in Version => CMake 2.8.5
2011-05-25 17:15 David Cole Resolution open => no change required
2011-10-03 09:54 David Cole Note Added: 0027508
2011-10-03 09:54 David Cole Status resolved => closed

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker