MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013841CMakeCMakepublic2013-01-09 04:282013-06-03 09:05
ReporterDavid Rosen 
Assigned To 
PrioritynoneSeveritytrivialReproducibilityalways
StatusclosedResolutionno change required 
PlatformXCode 4.5.2OSMac OS 10.7.5OS Version10.7.5
Product VersionCMake 2.8.10.2 
Target VersionFixed in Version 
Summary0013841: XCode post-build shell scripts fail
DescriptionWhen opening any XCode project that is built out-of-source, an error like this immediately appears, and the project cannot build:

PhaseScriptExecution "CMake Rules" /Users/david/Documents/OvergrowthSVN/TempBuild/Overgrowth.build/Debug/ZERO_CHECK.build/Script-57C6D205AA0E4C069EB19117.sh
    cd /Users/david/Documents/OvergrowthSVN/Projects
    /bin/sh -c /Users/david/Documents/OvergrowthSVN/TempBuild/Overgrowth.build/Debug/ZERO_CHECK.build/Script-57C6D205AA0E4C069EB19117.sh

make: CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug: No such file or directory
make: *** No rule to make target `CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug'. Stop.

I believe this error occurs because it is searching for the relative path "CMakeScripts/ZERO_CHECK_cmakeRulesBuildPhase.makeDebug", and expecting the working directory to be ${CMAKE_BINARY_DIR}. It is failing because immediately before running the script, XCode is calling "cd ${CMAKE_SOURCE_DIR}".

This seems to be because XCode calls "cd ${projectDirPath}" before calling any post-build shell scripts, and when CMake builds an XCode project, it sets the XCode "projectDirPath" value to ${CMAKE_SOURCE_DIR}. This can be observed by opening the pbxproj file and searching for "projectDirPath".
Steps To ReproduceUse CMake 2.8.10.2 to generate an XCode project with a different source and binary directory. Open the project with XCode 4.5.2. You should immediately see the error quoted in the description.

I have attached my project's CMakeLists.txt and subdirectories which have exhibited this problem on three computers, in case it does not occur on every CMake-created out-of-source XCode project.
Additional InformationThere are three paths that I see to solve this problem. First, the shell scripts could be given an absolute path, so it doesn't matter what the working directory is set to. Second, the projectDirPath could be set to ${CMAKE_BINARY_DIR} instead of ${CMAKE_SOURCE_DIR}. Third, and most preferable I think, the projectDirPath could just be left as "". That way the XCode project would not break if it is moved.

I have tested these approaches by manually changing the pbxproj file, and they all seem to solve the problem.
TagsNo tags attached.
Relationships
Attached Fileszip xcode_break_example.zip (32,184) 2013-01-09 04:28
https://public.kitware.com/Bug/file/4613/xcode_break_example.zip
Issue History
Date ModifiedUsernameFieldChange
2013-01-09 04:28David RosenNew Issue
2013-01-09 04:28David RosenFile Added: xcode_break_example.zip
2013-01-09 10:05Brad KingNote Added: 0032008
2013-01-09 13:51David RosenNote Added: 0032061
2013-01-09 14:06Brad KingNote Added: 0032085
2013-01-09 14:06Brad KingPriorityimmediate => none
2013-01-09 14:06Brad KingSeveritymajor => trivial
2013-01-09 14:06Brad KingStatusnew => resolved
2013-01-09 14:06Brad KingResolutionopen => no change required
2013-06-03 09:05Robert MaynardNote Added: 0033185
2013-06-03 09:05Robert MaynardStatusresolved => closed

Notes
(0032008)
Brad King   
2013-01-09 10:05   
The example project contains

 SET(CMAKE_USE_RELATIVE_PATHS ON CACHE BOOL "Use relative paths" FORCE )

That option is not really supported but exists because a few people claim it is useful. Does removing it solve the problem?
(0032061)
David Rosen   
2013-01-09 13:51   
That does seem to fix the problem (by giving the shell scripts an absolute path). Thank you!
(0032085)
Brad King   
2013-01-09 14:06   
The documentation of CMAKE_USE_RELATIVE_PATHS already warns it may not work:

 http://www.cmake.org/cmake/help/v2.8.10/cmake.html#variable:CMAKE_USE_RELATIVE_PATHS [^]
 "Use relative paths (May not work!). ... does not work for more complicated projects"
(0033185)
Robert Maynard   
2013-06-03 09:05   
Closing resolved issues that have not been updated in more than 4 months.