View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014297CMakeCMakepublic2013-07-16 21:352016-06-10 14:31
ReporterOscar Korz 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformAppleOSMac OS XOS Version10.8.3
Product VersionCMake 2.8.11.2 
Target VersionFixed in Version 
Summary0014297: XCode: Real targets do not depend on ZERO_CHECK
DescriptionALL_BUILD is a dummy target that depends on all other targets. This is convenient for building all the targets in the project. XCode supports parallel builds, so targets that are not dependent on each other are built simultaneously.

ZERO_CHECK is a dummy target that checks if the XCode project has become invalidated due to changes to CMake files. It may regenerate the project that is currently open.

In 2.8.11.2, only ALL_BUILD depends on ZERO_CHECK. If you build another specific target, ZERO_CHECK will not execute. This means that the XCode project will not validate itself. Building a specific executable is a convenient way to start debugging it, so this is a very common use case for my colleagues.

Additionally, I am concerned that ZERO_CHECK is run in parallel with real targets. Not only is this a wasted effort if the project needs to be regenerated, but more importantly I'm concerned that if an arbitrary project fails to compile, the ZERO_CHECK task may get terminated before it finishes and I'm not sure what effect this would have on the build tree. I have not confirmed this behavior, but I have noticed irregular behavior that is only occuring with XCode projects.
Steps To Reproduce1. Create an XCode project from CMake.

2. Change the target from ALL_BUILD to any real target (i.e. a library or executable).

3. Modify a CMake file used by the project. I suggest modifying the definition of the target you selected in step 2 as this is the worst case scenario.

4. Build the target (Command-B).
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0033564)
Brad King (manager)
2013-07-17 08:32

 With Xcode 4.6.3:

$ cmake --version
cmake version 2.8.11.2

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11.2)
project(Issue14297 C)
add_executable(real real.c)

$ cmake .. -GXcode

$ xcodebuild -configuration Debug -target real |grep BUILD
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
=== BUILD NATIVE TARGET real OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

$ touch ../CMakeLists.txt

$ xcodebuild -configuration Debug -target real |grep BUILD
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
=== BUILD NATIVE TARGET real OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

If I open the project in the IDE, select the "real" project,
and use Command-B, then the build output tab shows both targets.
(0033566)
Oscar Korz (reporter)
2013-07-17 17:24

 Thanks for the quick response!

I can confirm that with your simple test it works correctly:

$ xcodebuild -configuration Debug -target real | grep BUILD
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
=== BUILD NATIVE TARGET real OF PROJECT Issue14297 WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

However, something about my real project is causing problems:

$ xcodebuild -configuration Debug -target pal | grep BUILD
=== BUILD NATIVE TARGET pal OF PROJECT carlink WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

I'm trying now to figure out what about our project is causing issues so that we can determine if this is an edge case issue with the XCode generator or if we are doing something invalid in our project. If you have any ideas about what could be happening, please share.
(0033568)
Brad King (manager)
2013-07-18 08:38

 Re 0014297:0033566: Okay, moving to backlog awaiting a test case to reproduce this.

Did this newly appear in 2.8.11.x and worked in previous versions of CMake, or did you just happen to notice it now?

You'll have to strip the real project down incrementally. Does it happen with every "real" target or only some of them?
(0033569)
Brad King (manager)
2013-07-18 08:40

 Does anything in your project set CMAKE_SUPPRESS_REGENERATION?
(0033570)
Oscar Korz (reporter)
2013-07-18 17:54

 Re 0014297:0033568:

We've just moved to CMake, so we've only used 2.8.11. It's happening on every target. Only ALL_BUILD is depending on ZERO_CHECK.

Re 0014297:0033569:

CMAKE_SUPPRESS_REGENERATION is not used anywhere in our project.
(0033572)
Oscar Korz (reporter)
2013-07-18 18:05
edited on: 2013-07-18 18:07

 Okay, I think I've identified it. If I move your project to a subdirectory and create another CMakeLists that includes it, I no longer get ZERO_CHECK:

$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11)
project(bar)
add_subdirectory(foo)

$ cat foo/CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11.2)
project(Issue14297)
add_executable(real real.c)

$ cd build
$ xcodebuild -configuration Debug -target real | grep BUILD
=== BUILD NATIVE TARGET real OF PROJECT bar WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

Is this an invalid use of the project command? I've been using it in every subdirectory so that we can use the implicit variables project_SOURCE_DIR and project_BINARY_DIR without worrying about the exact location of every component.

If I add a target to the top level, it is correct. However, the other one is still broken:

$ cat ../CMakeLists.txt
cmake_minimum_required(VERSION 2.8.11)
project(bar)
add_executable(bar main.c)
add_subdirectory(foo)

$ xcodebuild -configuration Debug -target real | grep BUILD
=== BUILD NATIVE TARGET real OF PROJECT bar WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

$ xcodebuild -configuration Debug -target bar | grep BUILD
=== BUILD AGGREGATE TARGET ZERO_CHECK OF PROJECT bar WITH CONFIGURATION Debug ===
=== BUILD NATIVE TARGET bar OF PROJECT bar WITH CONFIGURATION Debug ===
** BUILD SUCCEEDED **

Edit: Note that use of projects in this way has not caused any problems with Unix Makefiles, NMake Makefiles, Visual Studio 9 2008 or Visual Studio 10. Only Xcode is having a problem.
(0033574)
Brad King (manager)
2013-07-19 08:26

 Re 0014297:0033572: That is a perfectly normal and legit way to arrange the project.

It appears that the "real" targets each end up with a dependency on the ZERO_CHECK target associated with the closest nested project()'s .xcodeproj directory. If I load foo/Issue14297.xcodeproj the dependency appears for "real". The Xcode generator needs to be fixed to match up the dependencies for the current .xcodeproj.
(0033575)
Brad King (manager)
2013-07-19 08:27

 Meanwhile you can work around this by not invoking project() anywhere except the top-level directory.
(0042320)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2013-07-16 21:35 Oscar Korz New Issue
2013-07-17 08:32 Brad King Note Added: 0033564
2013-07-17 17:24 Oscar Korz Note Added: 0033566
2013-07-18 08:38 Brad King Note Added: 0033568
2013-07-18 08:38 Brad King Status new => backlog
2013-07-18 08:40 Brad King Note Added: 0033569
2013-07-18 17:54 Oscar Korz Note Added: 0033570
2013-07-18 17:55 Oscar Korz Note Added: 0033571
2013-07-18 17:55 Oscar Korz Note Deleted: 0033571
2013-07-18 18:05 Oscar Korz Note Added: 0033572
2013-07-18 18:07 Oscar Korz Note Edited: 0033572
2013-07-19 08:26 Brad King Note Added: 0033574
2013-07-19 08:27 Brad King Note Added: 0033575
2016-06-10 14:29 Kitware Robot Note Added: 0042320
2016-06-10 14:29 Kitware Robot Status backlog => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team