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

Have you tried using CMAKE_CURRENT_LIST_DIR (introduced in 2.8.3)?

(0025699)
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.

(0025985)
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:

  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 (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.

(0025987)
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

  set(CMAKE_EXE_LINKER_FLAGS_INIT -myflag)

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

(0026004)
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?

(0026005)
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

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 (manager)
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 (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
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

Notes
(0025698) Rolf Eike Beer (developer) 2011-03-09 04:01	Have you tried using CMAKE_CURRENT_LIST_DIR (introduced in 2.8.3)?

(0025699) 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.

(0025985) 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: 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 (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.

(0025987) 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 set(CMAKE_EXE_LINKER_FLAGS_INIT -myflag) For this intended use case the fix of 0010902 was correct.

(0026004) 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?

(0026005) 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 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 (manager) 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 (manager) 2011-10-03 09:54	Closing resolved issues that have not been updated in more than 4 months.