(0023333)
Brad King (manager)
2010-11-17 09:56

Yes, 0010902 is the cause. CMAKE_USER_MAKE_RULES_OVERRIDE *has* to be used in try_compiles to support them in toolchains that need them (hence 0010902).

Running a try_compile inside the user rules script was never an anticipated, documented, or supported behavior. I can't believe it even worked accidentally before. The language initialization isn't finished at the time the script is loaded so the generators do not have enough information to produce fully correct build files.

What was the reason for this? There must be another way to do it.

(0023335)
Vladislav Vaintroub (reporter)
2010-11-17 10:18

>Running a try_compile inside the user rules script was never an anticipated, documented, or supported behavior.

Well, the documentation never stated what was anticipated or supported. This is a cmake file, and we added statements typical for CMake files and used it because it worked. And it is used to make MySQL releases, too

This page http://www.perkin.org.uk/ [^] describes how MySQL releases are done
(the -DBUILD_CONFIG=mysql_release parameter will cause inclusion of cmake/build_configurations/mysql_release.cmake, which has the CHECK_TYPE_SIZE and other stuff inside)

>I can't believe it even worked accidentally before.
You can check it, I can provide instructions for MySQL.

>What was the reason for this? There must be another way to do it.
The main reason is to find out the compiler bitness, some flags are set dependent on bitness (don't why, it was always been that way on Solaris)

(0023340)
Brad King (manager)
2010-11-17 10:26

Why can't those "bitness" flags be added after the fact:

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fancybitnessflag")

? Do they *have* to be in the cache for the user to edit/break?

(0023346)
Vladislav Vaintroub (reporter)
2010-11-17 10:43

They can be set later in theory, but what would be the purpose of the MAKE_USER_MAKE_RULES_OVERRIDE then ? We used this file to define all flags used by release builds, so that the flags are not spread around in different places.

(0023348)
Brad King (manager)
2010-11-17 10:49

The variable is meant as a last-resort for projects to pick alternative *default* values for the *cache* entries like CMAKE_C_FLAGS. The scripts can also override the platform file rules for running the compiler, but the need for this is generally outdated now by better per-compiler platform files.

Instead, just add your own release flags script inclusion:

  cmake_minimum_required(VERSION ...)
  project(MySQL ...)
  if(MySQL_RELEASE_RULES)
    include("${MySQL_RELEASE_RULES}")
  endif()

(0023351)
Rolf Eike Beer (developer)
2010-11-17 12:45

Why did you check the pointer size yourself? There is a CMAKE_SIZEOF_VOID_P.

(0023352)
Vladislav Vaintroub (reporter)
2010-11-17 12:52

There is CMAKE_SIZEOF_VOID_P, but not prior to PROJECT

(0023353)
Vladislav Vaintroub (reporter)
2010-11-17 16:15

Brad, yes, I think using INCLUDE would be the way to go. The single downside of it is not having flags in the cache. It is merely cosmetics, however the cached flags were used (at least in the past) for automation and verification work.

I created a bug for MySQL http://bugs.mysql.com/bug.php?id=58272 [^] and proposed a fix http://lists.mysql.com/commits/124202 [^] to fix the problem in MySQL, lets see if it gets accepted.

I guess the priority of that bug can be lowered now.

(0023354)
Brad King (manager)
2010-11-17 16:32

Okay, the "new" behavior of CMAKE_USER_MAKE_RULES_OVERRIDE is correct from CMake's point of view. Since it does not affect end-user MySQL builds but only packaging it is not as critical that we deal with this on the CMake end. If we do need to deal with it we will need to introduce a new policy.

Otherwise, this issue now remains open only as a task to get the MySQL contract test added to CMake.

(0023355)
Vladislav Vaintroub (reporter)
2010-11-17 16:42

I still think there is a better way to handle TRY_COMPILE inside CMAKE_USER_MAKE_RULES_OVERRIDE than the recursion and stack exhaustion. On Windows the output looks even more weird than on Linux..

It does affect our users somewhat, since we documented "How to build like we do in releases" on some places, but maybe if we manage to fix it quickly hopefully not many will notice.

(0023361)
Brad King (manager)
2010-11-17 17:18

Bill, cmGlobalGenerator::EnableLanguage should somehow block generation of build rules for a language until it is enabled fully (at least enough to load CMakeTest*Compiler.cmake). That way any try_compile command inside the override script would report an error from the generator.

(0025015)
David Cole (manager)
2011-01-21 19:14

Brad, is this fixed by your recent CMAKE_USER_MAKE_RULES_OVERRIDE change, or do we still need include blockers? (Or some other solution for this issue...?)

(0025023)
Brad King (manager)
2011-01-24 10:05

Blocker added:

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

Now if the override file does a try_compile one gets

CMake Error at /.../Modules/CheckIncludeFile.cmake:48 (TRY_COMPILE):
  The test project needs language C which is not enabled.
Call Stack (most recent call first):
  /.../Modules/CheckTypeSize.cmake:158 (check_include_file)
  UserOverride.cmake:2 (check_type_size)
  /.../Modules/CMakeCInformation.cmake:78 (INCLUDE)
  CMakeLists.txt:3 (project)

Issue History
Date Modified	Username	Field	Change
2010-11-17 09:11	Vladislav Vaintroub	New Issue
2010-11-17 09:11	Vladislav Vaintroub	File Added: my_project.tar.gz
2010-11-17 09:53	Brad King	Relationship added	related to 0010902
2010-11-17 09:56	Brad King	Note Added: 0023333
2010-11-17 10:18	Vladislav Vaintroub	Note Added: 0023335
2010-11-17 10:26	Brad King	Note Added: 0023340
2010-11-17 10:43	Vladislav Vaintroub	Note Added: 0023346
2010-11-17 10:49	Brad King	Note Added: 0023348
2010-11-17 12:45	Rolf Eike Beer	Note Added: 0023351
2010-11-17 12:52	Vladislav Vaintroub	Note Added: 0023352
2010-11-17 16:15	Vladislav Vaintroub	Note Added: 0023353
2010-11-17 16:30	Brad King	Assigned To	=> Bill Hoffman
2010-11-17 16:30	Brad King	Status	new => assigned
2010-11-17 16:32	Brad King	Note Added: 0023354
2010-11-17 16:42	Vladislav Vaintroub	Note Added: 0023355
2010-11-17 17:18	Brad King	Note Added: 0023361
2011-01-21 19:12	David Cole	Assigned To	Bill Hoffman => Brad King
2011-01-21 19:14	David Cole	Note Added: 0025015
2011-01-24 10:05	Brad King	Note Added: 0025023
2011-01-24 10:05	Brad King	Status	assigned => closed
2011-01-24 10:05	Brad King	Resolution	open => fixed
2011-01-31 16:10	David Cole	Fixed in Version	=> CMake 2.8.4
2011-01-31 16:10	David Cole	Target Version	=> CMake 2.8.4
2011-03-31 12:36	Brad King	Relationship added	related to 0011942

Notes
(0023333) Brad King (manager) 2010-11-17 09:56	Yes, 0010902 is the cause. CMAKE_USER_MAKE_RULES_OVERRIDE has to be used in try_compiles to support them in toolchains that need them (hence 0010902). Running a try_compile inside the user rules script was never an anticipated, documented, or supported behavior. I can't believe it even worked accidentally before. The language initialization isn't finished at the time the script is loaded so the generators do not have enough information to produce fully correct build files. What was the reason for this? There must be another way to do it.

(0023335) Vladislav Vaintroub (reporter) 2010-11-17 10:18	>Running a try_compile inside the user rules script was never an anticipated, documented, or supported behavior. Well, the documentation never stated what was anticipated or supported. This is a cmake file, and we added statements typical for CMake files and used it because it worked. And it is used to make MySQL releases, too This page http://www.perkin.org.uk/ [^] describes how MySQL releases are done (the -DBUILD_CONFIG=mysql_release parameter will cause inclusion of cmake/build_configurations/mysql_release.cmake, which has the CHECK_TYPE_SIZE and other stuff inside) >I can't believe it even worked accidentally before. You can check it, I can provide instructions for MySQL. >What was the reason for this? There must be another way to do it. The main reason is to find out the compiler bitness, some flags are set dependent on bitness (don't why, it was always been that way on Solaris)

(0023340) Brad King (manager) 2010-11-17 10:26	Why can't those "bitness" flags be added after the fact: set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fancybitnessflag") ? Do they have to be in the cache for the user to edit/break?

(0023346) Vladislav Vaintroub (reporter) 2010-11-17 10:43	They can be set later in theory, but what would be the purpose of the MAKE_USER_MAKE_RULES_OVERRIDE then ? We used this file to define all flags used by release builds, so that the flags are not spread around in different places.

(0023348) Brad King (manager) 2010-11-17 10:49	The variable is meant as a last-resort for projects to pick alternative default values for the cache entries like CMAKE_C_FLAGS. The scripts can also override the platform file rules for running the compiler, but the need for this is generally outdated now by better per-compiler platform files. Instead, just add your own release flags script inclusion: cmake_minimum_required(VERSION ...) project(MySQL ...) if(MySQL_RELEASE_RULES) include("${MySQL_RELEASE_RULES}") endif()

(0023351) Rolf Eike Beer (developer) 2010-11-17 12:45	Why did you check the pointer size yourself? There is a CMAKE_SIZEOF_VOID_P.

(0023352) Vladislav Vaintroub (reporter) 2010-11-17 12:52	There is CMAKE_SIZEOF_VOID_P, but not prior to PROJECT

(0023353) Vladislav Vaintroub (reporter) 2010-11-17 16:15	Brad, yes, I think using INCLUDE would be the way to go. The single downside of it is not having flags in the cache. It is merely cosmetics, however the cached flags were used (at least in the past) for automation and verification work. I created a bug for MySQL http://bugs.mysql.com/bug.php?id=58272 [^] and proposed a fix http://lists.mysql.com/commits/124202 [^] to fix the problem in MySQL, lets see if it gets accepted. I guess the priority of that bug can be lowered now.

(0023354) Brad King (manager) 2010-11-17 16:32	Okay, the "new" behavior of CMAKE_USER_MAKE_RULES_OVERRIDE is correct from CMake's point of view. Since it does not affect end-user MySQL builds but only packaging it is not as critical that we deal with this on the CMake end. If we do need to deal with it we will need to introduce a new policy. Otherwise, this issue now remains open only as a task to get the MySQL contract test added to CMake.

(0023355) Vladislav Vaintroub (reporter) 2010-11-17 16:42	I still think there is a better way to handle TRY_COMPILE inside CMAKE_USER_MAKE_RULES_OVERRIDE than the recursion and stack exhaustion. On Windows the output looks even more weird than on Linux.. It does affect our users somewhat, since we documented "How to build like we do in releases" on some places, but maybe if we manage to fix it quickly hopefully not many will notice.

(0023361) Brad King (manager) 2010-11-17 17:18	Bill, cmGlobalGenerator::EnableLanguage should somehow block generation of build rules for a language until it is enabled fully (at least enough to load CMakeTest*Compiler.cmake). That way any try_compile command inside the override script would report an error from the generator.

(0025015) David Cole (manager) 2011-01-21 19:14	Brad, is this fixed by your recent CMAKE_USER_MAKE_RULES_OVERRIDE change, or do we still need include blockers? (Or some other solution for this issue...?)

(0025023) Brad King (manager) 2011-01-24 10:05	Blocker added: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c83a834d [^] Now if the override file does a try_compile one gets CMake Error at /.../Modules/CheckIncludeFile.cmake:48 (TRY_COMPILE): The test project needs language C which is not enabled. Call Stack (most recent call first): /.../Modules/CheckTypeSize.cmake:158 (check_include_file) UserOverride.cmake:2 (check_type_size) /.../Modules/CMakeCInformation.cmake:78 (INCLUDE) CMakeLists.txt:3 (project)