MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015324CMakeCMakepublic2014-12-22 16:202015-11-02 09:13
ReporterBryce Glover 
Assigned ToBrad King 
PrioritylowSeveritymajorReproducibilitysometimes
StatusclosedResolutionfixed 
PlatformMid-2007 24" iMacOSOS XOS Version10.10.1
Product VersionCMake 3.1 
Target VersionCMake 3.2Fixed in VersionCMake 3.2 
Summary0015324: Xcode generator fails to re-configure existing build tree when CMake has moved
DescriptionIf one runs the command 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' after updating CMake from version 3.0.2 to version 3.1.0 when this directory was last populated by CMake 3.0.2.
Steps To Reproduce1.) Make sure that CMake 3.0.2 is installed.
2.) Run 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' via Terminal.
3.) Update CMake from version 3.0.2 to version 3.1.0.
4.) Run 'cmake -G "Xcode" [project-location]' from within '[project-location]/build/' via Terminal again.
5.) CMake should crash when 'Checking for a C compiler using Xcode….'
Additional InformationThe project I'm having trouble with is LLVM/Clang/compiler-rt/test-suite, and I use Homebrew in order to keep CMake up to date.
TagsClang, CMake, compiler, compiler-rt, intel, LLVM, macosx, make, test-suite, Xcode
Relationships
Attached Fileslog CMakeError.log (133,161) 2015-01-25 17:55
https://public.kitware.com/Bug/file/5362/CMakeError.log
log CMakeOutput.log (704,152) 2015-01-25 17:56
https://public.kitware.com/Bug/file/5363/CMakeOutput.log
Issue History
Date ModifiedUsernameFieldChange
2014-12-22 16:20Bryce GloverNew Issue
2014-12-22 16:23Bryce GloverTag Attached: CMake
2014-12-22 16:23Bryce GloverTag Attached: compiler
2014-12-22 16:23Bryce GloverTag Attached: intel
2014-12-22 16:23Bryce GloverTag Attached: macosx
2014-12-22 16:23Bryce GloverTag Attached: make
2014-12-22 16:23Bryce GloverTag Attached: Xcode
2014-12-22 16:36Brad KingNote Added: 0037513
2014-12-22 21:46Bryce GloverNote Added: 0037519
2014-12-22 21:54Bryce GloverNote Added: 0037520
2014-12-22 21:55Bryce GloverNote Edited: 0037520bug_revision_view_page.php?bugnote_id=37520#r1656
2014-12-23 15:23Bryce GloverTag Attached: Clang
2014-12-23 15:23Bryce GloverTag Attached: compiler-rt
2014-12-23 15:23Bryce GloverTag Attached: LLVM
2014-12-23 15:23Bryce GloverTag Attached: test-suite
2015-01-04 18:22Bryce GloverNote Added: 0037552
2015-01-09 18:25Bryce GloverNote Added: 0037657
2015-01-11 15:04Brad KingNote Added: 0037665
2015-01-11 15:04Brad KingStatusnew => resolved
2015-01-11 15:04Brad KingResolutionopen => unable to reproduce
2015-01-25 17:54Bryce GloverNote Added: 0037804
2015-01-25 17:55Bryce GloverFile Added: CMakeError.log
2015-01-25 17:56Bryce GloverFile Added: CMakeOutput.log
2015-01-25 17:57Bryce GloverNote Added: 0037805
2015-01-26 10:40Brad KingNote Added: 0037813
2015-01-26 14:11Bryce GloverNote Added: 0037819
2015-01-26 14:38Bryce GloverNote Added: 0037821
2015-01-27 11:51Brad KingNote Added: 0037841
2015-01-27 14:14Bryce GloverNote Added: 0037845
2015-01-27 17:55Bryce GloverNote Added: 0037847
2015-01-28 10:24Brad KingSeveritycrash => major
2015-01-28 10:24Brad KingStatusresolved => acknowledged
2015-01-28 10:24Brad KingResolutionunable to reproduce => open
2015-01-28 10:24Brad KingSummaryCMake 3.1.0 Crashes When Told to Regenerate a Project Originally Generated Under CMake 3.0.2 => Xcode generator fails to re-configure existing build tree when CMake has moved
2015-01-28 10:26Brad KingNote Added: 0037851
2015-01-29 09:22Brad KingNote Added: 0037856
2015-01-29 09:22Brad KingAssigned To => Brad King
2015-01-29 09:22Brad KingStatusacknowledged => resolved
2015-01-29 09:22Brad KingResolutionopen => fixed
2015-01-29 09:22Brad KingFixed in Version => CMake 3.2
2015-01-29 09:22Brad KingTarget Version => CMake 3.2
2015-01-30 13:29Bryce GloverNote Added: 0037870
2015-02-04 12:03Bryce GloverNote Added: 0037904
2015-02-15 12:22Bryce GloverNote Added: 0037978
2015-02-16 08:51Brad KingNote Added: 0037980
2015-02-16 13:20Bryce GloverNote Added: 0037983
2015-02-16 13:24Brad KingNote Added: 0037984
2015-02-16 16:15Bryce GloverNote Added: 0037986
2015-03-14 10:13Bryce GloverNote Added: 0038214
2015-03-15 10:33Brad KingNote Added: 0038216
2015-03-15 17:47Bryce GloverNote Added: 0038220
2015-11-02 09:13Robert MaynardNote Added: 0039731
2015-11-02 09:13Robert MaynardStatusresolved => closed

Notes
(0037513)
Brad King   
2014-12-22 16:36   
I'm not able to reproduce this. Please test with the upstream CMake installer and provide full instructions on what to download and build, or ideally a minimal source tree that reproduces it.
(0037519)
Bryce Glover   
2014-12-22 21:46   
Didn't I say in my original bug report's 'Additional Information' section that I keep CMake up to date using Homebrew? (Or was it Homebrew Cask? I'll have to check….) If you install CMake using that, then you might be able to reproduce what I'm seeing. Maybe it has to do with how Homebrew (Cask) manages different versions of the same kind of software? If I remember correctly, what Homebrew does when it updates users to a newer version of a piece of software is create a new folder for this version's source code inside of a folder that it has set aside for the software in question and then fetches and builds that source code; the one or more resulting executables are then added to where they would normally be installed using one or more symbolic links. Maybe this might mess up how CMake is configured by resetting its configuration back to whatever the default one is? As for a minimal source tree that you might be able to use to reproduce what I saw before force-resetting, I'll have to get back to you on that one….
(0037520)
Bryce Glover   
2014-12-22 21:54   
(edited on: 2014-12-22 21:55)
OK, I just checked on whether my installation of CMake is managed by Homebrew or Homebrew Cask, and I found out that my copy of CMake is managed just by plain-old Homebrew and not by Homebrew Cask. Now I just need to provide you with what you called 'full instructions on what to download and build' so that you can reproduce what I saw just after I upgraded to CMake 3.1.0…unfortunately, that may have to wait until tomorrow.
(0037552)
Bryce Glover   
2015-01-04 18:22   
I'd like to apologize for telling you I could get those details you wanted from me so soon before Christmas and then not keeping that promise. I'll get them to you as soon as I possibly can, okay?
(0037657)
Bryce Glover   
2015-01-09 18:25   
Never mind; I tested it again and I'm pretty sure it only breaks when you sync your repository between CMake updates.
(0037665)
Brad King   
2015-01-11 15:04   
Okay, thanks.
(0037804)
Bryce Glover   
2015-01-25 17:54   
Hey, Brad; I just found out that this bug is also reproducible after updating from CMake 3.1.0 to CMake 3.1.1. Here are the commands I used…:

cd /Volumes/Development/Repositories/llvm/
     /* '/Volumes/Development' is a case-sensitive sparse disk image I created to hold all of my development stuff so I wouldn't have to make my main drive case-sensitive and break whatever applications and parts of OS X depend on your boot drive being case-insensitive. */
git checkout master && git pull -v
cd ./tools/clang/
git checkout master && git pull -v
cd ./tools/extra/
git checkout master && git pull -v
cd ../../../../projects/compiler-rt/
git checkout master && git pull -v
cd ../test-suite/
git checkout master && git pull -v
cd /Volumes/Development/Repositories/llvm/build
make -G "Xcode" ../

…and here's the resulting error message:

Bryces-HD-1-TB:build bryce$ cmake -G "Xcode" ../
-- The C compiler identification is AppleClang 6.0.0.6000056
-- The CXX compiler identification is AppleClang 6.0.0.6000056
-- Check for working C compiler using: Xcode
CMake Error: Generator: execution of make failed. Make command was: "/usr/local/Cellar/cmake/3.0.2/bin/cmakexbuild" "-project" "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTryCompileExec2113745060" "-configuration" "Debug"
-- Check for working C compiler using: Xcode -- broken
CMake Error at /usr/local/Cellar/cmake/3.1.1/share/cmake/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler
  "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
  is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /Volumes/Development/Repositories/llvm/build/CMakeFiles/CMakeTmp

  

  Run Build Command:"/usr/local/Cellar/cmake/3.0.2/bin/cmakexbuild"
  "-project" "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target"
  "cmTryCompileExec2113745060" "-configuration" "Debug"

  No such file or directory

  Generator: execution of make failed. Make command was:
  "/usr/local/Cellar/cmake/3.0.2/bin/cmakexbuild" "-project"
  "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target"
  "cmTryCompileExec2113745060" "-configuration" "Debug"

  

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:25 (project)


-- Configuring incomplete, errors occurred!
See also "/Volumes/Development/Repositories/llvm/build/CMakeFiles/CMakeOutput.log".
See also "/Volumes/Development/Repositories/llvm/build/CMakeFiles/CMakeError.log".

I'll attach CMakeOutput.log and CMakeError.log soon, and I'm pretty sure that the reason why command that CMake tried to use to generate an LLVM.xcodeproj is because I got a similar error last time. (I thought I remembered the error message I got after updating from CMake 3.0.2 to CMake 3.1.0 was similar, as it had mentioned failure at CMakeLists.txt, line 25, but I wasn't quite sure because I accidentally deleted the old CMakeOutput.log and CMakeError.log before I submitted this bug in the first place. Oops!)
(0037805)
Bryce Glover   
2015-01-25 17:57   
OK, I just uploaded CMakeOutput.log and CMakeError.log, so hopefully we can figure out what's going on from those puppies.
(0037813)
Brad King   
2015-01-26 10:40   
Re 0015324:0037804: Interesting, thanks.

It's a long procedure to try to reproduce this so I want set things up as closely as possible. I see this note:

 '/Volumes/Development' is a case-sensitive sparse disk image

Can you reproduced this with a case-insensitive filesystem?

Also, please use CMake 3.0 and 3.1 from these images:

  http://www.cmake.org/files/v3.0/cmake-3.0.2-Darwin64-universal.dmg [^]
  http://www.cmake.org/files/v3.1/cmake-3.1.1-Darwin-x86_64.dmg [^]

You should be able to run them right out of the volume mount in the .app/Contents/bin folder.

Please report exactly the Git remotes and sha1s of the repository you have checked out for each step.
(0037819)
Bryce Glover   
2015-01-26 14:11   
Actually, I may not have to: you see, '/Volumes/Development/' is only for my repositories and projects. All of my applications, including CMake's command-line and GUI interfaces, are installed on my boot disk. As for using the disk images you provided for installation of CMake, I usually have Homebrew build the CMake command-line tools from the source code. I'll get you the remotes and SHA1 hashes for each of the repositories I checked out as soon as I can, all right?
(0037821)
Bryce Glover   
2015-01-26 14:38   
OK, here are the remotes and SHA1 hashes for each repository I cloned:

- '/Volumes/Development/Repositories/llvm/' currently points to http://llvm.org/git/llvm.git [^] at revision '48e872230d2a67639b365876958c87bb4637d681.'
- '/Volumes/Development/Repositories/llvm/tools/clang/' currently points to http://llvm.org/git/clang.git [^] at revision '28dfa35addb4a4fcd35c9e3b656f919e456e4021.'
- '/Volumes/Development/Repositories/llvm/tools/clang/tools/extra/' currently points to http://llvm.org/git/clang-tools-extra.git [^] at revision 'cd3151b37c65708ba13ffa61b2f7d516d7eab73b.'
- '/Volumes/Development/Repositories/llvm/projects/compiler-rt' currently points to http://llvm.org/git/compiler-rt.git [^] at revision '7b18e4e66968babf93cdd9aec5c85c742e015247.'
- '/Volumes/Development/Repositories/llvm/projects/test-suite' currently points to http://llvm.org/git/test-suite.git [^] at revision '48005f3979872c4a137d5ffc1b8e1ad7acd878c4.'

Please do note, however, that I tend to update each of these using 'git checkout master && git pull -v' each time I get on my computer. If you want me to modify this post to tell you when I update things or create a new post where I do that, then just let me know. Also, I'm not sure if the particular revisions matter at all; remember that all you have to do in order to reproduce this bug is run 'cmake -G "Xcode" ../' from within a new directory named '/Volumes/Development/Repositories/llvm/build' after initially cloning each of the repositories involved to the paths I've specified, wait until at least some of the repositories involved has been updated with new commits, pull in each repository's latest commits, and try and run CMake again.
(0037841)
Brad King   
2015-01-27 11:51   
Re 0015324:0037804: I just realized the behavior you report is not actually a crash (as in a segmentation fault), but a failure to re-configure. The reason is right in the output message:

   Run Build Command:"/usr/local/Cellar/cmake/3.0.2/bin/cmakexbuild" ...
   No such file or directory

The path to an older version's cmakexbuild is recorded in CMAKE_MAKE_PROGRAM in the CMakeCache.txt file. Since it was removed and the path to the new cmakexbuild has a different version number, this breaks. The reason I couldn't reproduce this is because I was updating the CMake version in-place or testing two versions of CMake that both remain installed.

The cmakexbuild tool is a wrapper around xcodebuild left from older Xcode versions that spewed the entire environment out before every build step. The wrapper filters out the extra output. We should check whether it is still needed.
(0037845)
Bryce Glover   
2015-01-27 14:14   
Re 0015324:0037841: Sorry! I didn't know that you thought of a 'crash' as a 'crash due to a segmentation fault!' (There are other kinds of crashes, you know!)
(0037847)
Bryce Glover   
2015-01-27 17:55   
@Brad: In your last post, you said the following:

> I just realized the behavior you report is not actually a crash (as in a segmentation fault), but a
> failure to re-configure. The reason is right in the output message:
>
> Run Build Command:"/usr/local/Cellar/cmake/3.0.2/bin/cmakexbuild" ...
> No such file or directory
>
> The path to an older version's cmakexbuild is recorded in CMAKE_MAKE_PROGRAM in the
> CMakeCache.txt file. Since it was removed and the path to the new cmakexbuild has a different
> version number, this breaks. The reason I couldn't reproduce this is because I was updating the
> CMake version in-place or testing two versions of CMake that both remain installed.
>
> The cmakexbuild tool is a wrapper around xcodebuild left from older Xcode versions that spewed
> the entire environment out before every build step. The wrapper filters out the extra output. We
> should check whether it is still needed.

Can you tell me where exactly (presumably a thread on one of CMake mailing lists) you are going to discuss this so that I can follow this discussion?
(0037851)
Brad King   
2015-01-28 10:26   
Re 0015324:0037847: Currently this is just on my personal todo list. It shouldn't need discussion. The Visual Studio generators avoid storing CMAKE_MAKE_PROGRAM in the cache since CMake 3.0. The Xcode generator may need a similar update.
(0037856)
Brad King   
2015-01-29 09:22   
The following commits should fix this for the future:

 Xcode: Add internal API to find xcodebuild
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e4055a61 [^]

 Xcode: Select make program at build time
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11e2e6ca [^]

 Xcode: Switch to internal CMAKE_MAKE_PROGRAM lookup by generator
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab9fa54d [^]

In order to continue to support user-specified CMAKE_MAKE_PROGRAM values we must continue to honor any such value in the cache. Therefore even with this fix in CMake 3.2, any build trees created with CMake 3.1 and lower will still break when upgrading unless you manually unset CMAKE_MAKE_PROGRAM. This can be done by removing the line from CMakeCache.txt or by running the new CMake with "-DCMAKE_MAKE_PROGRAM=".
(0037870)
Bryce Glover   
2015-01-30 13:29   
OK, thanks! Oh, and apparently, changing CMAKE_MAKE_PROGRAM to reflect the path to the copy of cmakexbuild installed by Homebrew as part of the latest version of CMake works, too.
(0037904)
Bryce Glover   
2015-02-04 12:03   
@Brad: When's CMake 3.2.0 coming out, anyway?
(0037978)
Bryce Glover   
2015-02-15 12:22   
Never mind, the CMake roadmap says that CMake 3.2 is on track to be released toda
(0037980)
Brad King   
2015-02-16 08:51   
Re 0015324:0037978: 3.2.0-rc1 was announced:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51749 [^]
(0037983)
Bryce Glover   
2015-02-16 13:20   
@Brad: Um, that seems to be the wrong thread since it talks about the release of CMake 3.1.3 instead of the release of CMake 3.2rc1.
(0037984)
Brad King   
2015-02-16 13:24   
Sorry:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12392 [^]
(0037986)
Bryce Glover   
2015-02-16 16:15   
OK, thanks!
(0038214)
Bryce Glover   
2015-03-14 10:13   
I've got the fix! For some weird reason, though, Homebrew didn't notify me to install CMake 3.2.0 when its consumer release came out and instead waited until CMake 3.2.1 came out to tell me there was an update. I guess it doesn't really matter now, though, does it? Next time something like this happens, though, I'm going to take it up with the guys over at Homebrew…unless you guys want to start contributing to updates to that project's CMake download/update script?
(0038216)
Brad King   
2015-03-15 10:33   
Re 0015324:0038214: It's not Homebrew's fault. We never announced 3.2.0 because a fairly important regression was reported after tagging but before announcing. We skipped to 3.2.1 for the release announcement.
(0038220)
Bryce Glover   
2015-03-15 17:47   
Ah, thanks for clearing that up! I never saw anything about that on the mailing lists, though. Guess I'd better pay more attention, eh?
(0039731)
Robert Maynard   
2015-11-02 09:13   
Closing resolved issues that have not been updated in more than 4 months.