|
Notes |
|
|
(0027956)
|
|
David Rogers
|
|
2011-12-13 12:24
|
|
|
Sorry, I screwed up. replace 4.2 with 4.3. |
|
|
|
(0028186)
|
|
Rowan James
|
2012-01-04 23:18
(edited on: 2012-01-04 23:20) |
|
Confirming this issue with Xcode 4.3 DP 2
Using Xcode to run 'shell script' build stages for external library targets, I've found that I can work around this issue with the environment variables for the toolchain and SDK directories that Xcode provides, like so:
PATH="${DT_TOOLCHAIN_DIR}/usr/bin:$PATH"
CC="$SDK_DIR/usr/bin/clang -L${SDK_DIR}/usr/lib"
cmake -DCMAKE_MAKE_PROGRAM="${SYSTEM_DEVELOPER_BIN_DIR}/make" -DCMAKE_INCLUDE_PATH="${SDK_DIR}/usr/include" -DCMAKE_LIBRARY_PATH="${SDK_DIR}/usr/lib" ../src
---
In my case, the variables expand roughly as:
SDK_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
DT_TOOLCHAIN_DIR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain
SYSTEM_DEVELOPER_BIN_DIR=/Applications/Xcode.app/Contents/Developer/usr/bin
|
|
|
|
(0028605)
|
|
David Rogers
|
|
2012-02-16 10:07
|
|
|
Xcode 4.3 has now been released and this has not been resolved on Apple's side so it looks like it will be up to you guys. |
|
|
|
(0028608)
|
|
Sean McBride
|
|
2012-02-16 12:10
|
|
Damn, you're right. /Developer is gone. The Xcode.app bundle now contains other apps like Instruments and the SDKs and headers. Weird.
You really should correct this bug's title to be 4.3 not 4.2. |
|
|
|
(0028609)
|
|
David Rogers
|
|
2012-02-16 12:19
|
|
|
I would love to but I don't have permission. Could an admin update the bug title for me? |
|
|
|
(0028610)
|
|
Sean McBride
|
|
2012-02-16 12:39
|
|
|
|
|
(0028611)
|
|
David Rogers
|
|
2012-02-16 13:13
|
|
Thanks for the link. With those tools installed we get this error:
xcodebuild: error: option '-buildstyle' is no longer supported |
|
|
|
(0028613)
|
|
Chris H
|
|
2012-02-17 07:28
|
|
The xcodebuild -buildstyle error happens because cmake falls back to using the Xcode 1.5 specific generator code. You can work around this by copying /Applications/Xcode.app/Contents/version.plist to /Developer/Applications/Xcode.app/Contents/version.plist.
Also, the generated projects reference the SDK in /Developer, this must be manually fixed before building. |
|
|
|
(0028638)
|
|
Francisco Requena Espí
|
|
2012-02-19 17:43
|
|
We're having the same issue here, cause we've moved to Xcode 4.3.
Is this planned to be fixed anytime soon?
Thanks. |
|
|
|
(0028642)
|
|
aw70
|
|
2012-02-20 09:01
|
|
|
I can only second the wish for a really, really fast-track solution to this. We updated to Xcode 4.3 because our legacy cross-platform project (don't ask - one of "those" projects) managed to repeatably and consistently crash Xcode 4.2 during development. 4.2 built useable binaries, but having to re-start Xcode at least once during each build was fairly unnerving. So we jumped to Xcode 4.3 ASAP. Bad move, as it turned out... |
|
|
|
(0028647)
|
|
Francisco Requena Espí
|
2012-02-20 12:14
(edited on: 2012-02-20 12:15) |
|
I've attached a temporal fix. It worked for me. Apply to the git repository, did it on tag 2.8.7. Hope it helps.
|
|
|
|
(0028648)
|
|
David Rogers
|
|
2012-02-20 12:41
|
|
|
Thanks for the patch. It works great! The only issue that could arise that I see is if someone moves Xcode out of /Applications then this will fail again. |
|
|
|
(0028649)
|
|
Sean McBride
|
|
2012-02-20 12:59
|
|
|
Hardcoding those paths seems fragile. See the xcode-select man page. Maybe we can use "xcode-select -print-path" |
|
|
|
(0028650)
|
|
Francisco Requena Espí
|
2012-02-20 13:02
(edited on: 2012-02-20 13:04) |
|
It's quite fragile indeed, and I don't like it that much. It's definitely not a serious fix, but a temporal solution until someone takes care of it (and does a better job).
About xcode-select, yes, I think it's a more appropriate solution.
|
|
|
|
(0028651)
|
|
aw70
|
|
2012-02-20 13:14
|
|
Thanks a lot for the patch! I had to perform some manual tweaks to the generated .xcodeproj in order for the whole thing to actually build again, though. In particular, the patched cmake still had trouble figuring out the isysroot variables. So what you posted is most likely not a complete fix for the problem. Also, I had to run xcode-select so cmake would run at all (the compiler test failed before that).
But then, what I am working with here is a rather odd project that generates a shared library (actually, on OS X, a framework), plus a bunch of command line programs that use said framework. And at least it is compiling again. So I'm not complaining - many thanks for having a working fix at such short notice! |
|
|
|
(0028652)
|
|
Sean McBride
|
|
2012-02-20 13:17
|
|
|
Francisco, I know your patch is just a quick fix, I only wanted to make sure you (and everyone) knew about xcode-select... |
|
|
|
(0028653)
|
|
Francisco Requena Espí
|
|
2012-02-20 13:45
|
|
|
Yeah, thanks for that :) I forgot to talk about setting up "xcode-select". |
|
|
|
(0028654)
|
|
Graham Perks
|
|
2012-02-20 13:49
|
|
It doesn't look like xcode-select is giving the correct output. I installed Xcode 4.3 and 'xcode-select -print-path' says '/Developer'. I have no longer have a /Developer!
This is before and after installing Xcode's command line tools. |
|
|
|
(0028655)
|
|
Francisco Requena Espí
|
|
2012-02-20 13:51
|
|
If you're moving from previous versions, I think you should change it:
xcode-select -switch /Applications/Xcode.app |
|
|
|
(0028656)
|
|
Graham Perks
|
|
2012-02-20 13:53
|
|
|
To get past the xcode-select issue, run: sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/ |
|
|
|
(0028658)
|
|
Graham Perks
|
|
2012-02-20 14:39
|
|
Either way, when I generate an Xcode project I get warnings about "Missing SDK in target..." and indeed it has the wrong path. It has:
/Applications/Xcode.app/Contents/Developer/SDKs/MacOSX10.7.sdk
Ought to be:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
This is after applying the patch provided above. |
|
|
|
(0028659)
|
|
Graham Perks
|
|
2012-02-20 14:56
|
|
|
Is there already a CMAKE flag to tell it to use the generic "Latest SDK", like Xcode allows you to choose, rather than a specific SDK path? |
|
|
|
(0028663)
|
|
Francisco Requena Espí
|
|
2012-02-20 16:12
|
|
It's weird, my application is linking to SDK 10.7, and handles it properly. I'm using Lion. It's clean, just formatted everything, and used Xcode 4.3 directly (no upgrading from 4.2).
It's not like it will solve the problem, but could you try doing xcode-select -switch /Applications/Xcode.app? (not xcode-select -switch /Applications/Xcode.app/Contents/Developer/)
PD: Maybe "man xcode-select" helps. Also, in Xcode's Preferences > Downloads, if you have Command Line Tools installed, click it and expand the lower icon (in order to get the description). That description may be useful (talks about xcode-select and xcrun) |
|
|
|
(0028665)
|
|
Graham Perks
|
|
2012-02-20 17:01
|
|
|
I tried both xcode-select styles, both result in the Missing SDK problem. I don't have anything in my CMakeLists.txt file about choosing an SDK - is there something I should add? |
|
|
|
(0028666)
|
|
aw70
|
|
2012-02-20 17:06
|
|
|
FWIW, I also have the issue of an invalid SDK being chosen in the Xcode project. This is what I was referring to with "I had to edit some things by hand". In my case, everything works as expected once I manually select the correct targets. |
|
|
|
(0028667)
|
|
Francisco Requena Espí
|
|
2012-02-20 17:12
|
|
Hmm, are you using an existing Cache or something?
I think we'll need to check how CMake currently resolves that path. |
|
|
|
(0028669)
|
|
aw70
|
|
2012-02-20 17:28
|
|
In my case, I I got rid of all caches (and the Xcode project) entirely before re-creating the project with the patched CMake. And with "invalid SDK", I mean one with a malformed path. As in: /Applications/Xcode.app/Contents/Developer/SDKs/MacOSX10.7.sdk, or something similar.
In case you have a hard time replicating this defective behaviour with your own projects: the stuff I'm working on is a project I could privately share with the cmake developers, if you are interested. Contact me directly if you feel that this might help you. |
|
|
|
(0028719)
|
|
Thomas Goddard
|
2012-02-25 04:19
(edited on: 2012-02-25 04:20) |
|
The patch included in 2.8.7 does not work. The reason is that the patch stats /Developer/Applications/Xcode.app first, which most people don't have if they have Lion and Xcode in a fresh install. It looks like a small oversight. It should stat /Applications/Xcode.app, then if it exists, use that of course.
|
|
|
|
(0028720)
|
|
Francisco Requena Espí
|
|
2012-02-25 04:22
|
|
|
I'm on a fresh Lion install. Just downloaded Xcode 4.3 from App Store. Have you tried xcode-select? |
|
|
|
(0028721)
|
|
Jamie Kirkpatrick
|
|
2012-02-25 09:30
|
|
I have a patch that fixes compatibility with Xcode 4.3 on systems without older versions of Xcode installed: https://github.com/Kitware/CMake/pull/15 [^]
It assumes the user has installed the CLI tools by opening the Xcode preferences window and choosing them from there. |
|
|
|
(0028747)
|
|
Andrew Hill
|
|
2012-02-28 23:01
|
|
|
Jamie Kirkpatrick's patch works for me (after fixing up the xcode-select path as noted above) |
|
|
|
(0028749)
|
|
Andrew Hill
|
2012-02-29 06:18
(edited on: 2012-02-29 06:27) |
|
Ok so I may have spoken too soon.
I had a previous work-around still partially in place (some symlinks in /Developer to point to places in the new Xcode.app). One such symlink was linking /Developer/SDKs to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/.
After removing /Developer entirely, and deleting + rebuilding my projects, they stopped working again, giving me an error about no valid destination when trying to build any target. Also noticed that CMAKE_OSX_SYSROOT was pointing at a directory that didn't exist.
Setting CMAKE_OSX_SYSROOT to this path fixed the problem:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
It looks like Apple have moved/restructured the location of SDKs, and instead of being at:
`xcode-select -print-path`/SDKs
There are now:
`xcode-select -print-path`/Platforms/MacOSX.platform/Developer/SDKs
`xcode-select -print-path`/Platforms/iPhoneOS.platform/Developer/SDKs
`xcode-select -print-path`/Platforms/iPhoneSimulator.platform/Developer/SDKs
Alternatively a symlink in /Applications/Xcode.app/Contents/Developer/, pointing to 'Platforms/MacOSX.platform/Developer/SDKs' seemed to work too.
|
|
|
|
(0028750)
|
|
Andrew Hill
|
2012-02-29 07:01
(edited on: 2012-02-29 07:36) |
|
I've posted comments about Jamie Kirkpatrick's patch on his pull request, and will duplicate here:
----
In Modules/Platform/Darwin.cmake, the variable CMAKE_OSX_SYSROOT is set based on lines 104 to 130.
While OSX_DEVELOPER_ROOT has likely been updated from the output of xcode-select (at least, if there's no /Developer directory), they reference the old (pre-Xcode-4.3) path structure:
${OSX_DEVELOPER_ROOT}/SDKs/MacOSX${_CURRENT_OSX_VERSION}.sdk
For me, this resolves to /Applications/Xcode.app/Contents/Developer/SDKs/MacOSX10.7.sdk, which doesn't exist.
(hence me having to enter it manually for cmake)
Instead, it should be finding /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk (as per the changes made to lines 74-76).
----
Also was just thinking that the test for the xcode-select utility (lines 68-72) should probably come before trying the hard-coded "/Developer" value for OSX_DEVELOPER_ROOT (line 60). Otherwise cmake will always ignore Xcode 4.3 if you have any previous version installed alongside it.
The first test should be to see if xcode-select exists, and whether it offers a useful path, falling back on "/Developer" if it doesn't. And only then should cmake start poking around in OSX_DEVELOPER_ROOT to find the right SDKs dir.
And later on, when setting CMAKE_OSX_SYSROOT, it should probably use the OSX_DEVELOPER_ROOT value instead of ${OSX_DEVELOPER_ROOT}/SDKs.
Even though this is starting to change some default behaviour (not just a basic fix), so is perhaps a bit beyond the scope of *this issue*, it strikes me as being important for Xcode 4.3 compatibility.
(compared to CMake master branch, my line numbers will be out by 3, if greater than 74, due to additional 3 lines in the patch)
----
Have attached cmake-xcode-4.3-compat.patch which is based on Jamie's pull request and addresses the above.
|
|
|
|
(0028758)
|
|
Thomas Harning
|
|
2012-02-29 14:17
|
|
|
Note: this is also relevant for xcode 4.4 (Using Mountain Lion dev preview) |
|
|
|
(0028765)
|
|
aw70
|
|
2012-02-29 17:56
|
|
|
One additional data point for you: cmake-xcode-4.3-compat.patch seems to work flawlessly for me, for a fairly complex project that generates both a framework, and several command line apps that depend on it. OS X 10.73, and I only have Xcode 4.3 on the machine, with no old XCode being retained. |
|
|
|
(0028766)
|
|
Timothee Besset
|
|
2012-02-29 20:32
|
|
I am using the next branch with the cmake-xcode-4.3-compat.patch applied:
cmake version 2.8.7.20120229-gb7153-dirty
I only have Xcode 4.3 on the system, cmake generated the project files just fine, looks good. |
|
|
|
(0028771)
|
|
Torsten Maehne
|
2012-03-01 10:25
(edited on: 2012-03-01 10:26) |
|
I applied cmake-xcode-4.3-compat.patch to the cmake 2.8.7 tar ball, After installing the command line tools from within Xcode 4.3 and doing:
$ xcode-select -switch /Applications/Xcode.app/Contents/Developer
CMake is able to generate again Unix Makefiles and Xcode projects for my projects without errors.
|
|
|
|
(0028802)
|
|
David Cole
|
|
2012-03-03 14:56
|
|
Since we are preferring the "/Applications" location in the C++ code to look up the version of Xcode, I think we should also prefer the 4.3+ SDK locations first, before falling back to the older SDK locations. Does that seem reasonable to everybody watching here?
Thx,
David C. |
|
|
|
(0028803)
|
|
Garth Snyder
|
|
2012-03-04 00:08
|
|
----
Since we are preferring the "/Applications" location in the C++ code to look up the version of Xcode, I think we should also prefer the 4.3+ SDK locations first, before falling back to the older SDK locations. Does that seem reasonable to everybody watching here?
----
That sounds reasonable to me.
Apple's release notes mention the option of leaving the old versions of the developer tools installed even under 4.3, so that's apparently at least a somewhat supported configuration. If the path precedences aren't treated consistently, I would imagine it's just an invitation to hard-to-diagnose version skew problems.
On my development system, which is 4.3-only but previously had 4.2 installed, the cmake-xcode-4.3-compat.patch and xcode-select fixes seem to work fine. |
|
|
|
(0028806)
|
|
Ramkumar Thiyyakat
|
|
2012-03-05 02:44
|
|
Hi All,
I'm very new to Cmake and I don't know how to apply patch files.While running cmake -G Xcode command I'm getting
-- Check for working C compiler using: Xcode -- broken
CMake Error at /Applications/CMake 2.8-7.app/Contents/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/ramkumar/MySQL/mysql-connector-c-6.0.2/CMakeFiles/CMakeTmp
Run Build Command:/Applications/CMake\ 2.8-7.app/Contents/bin/cmakexbuild
-project CMAKE_TRY_COMPILE.xcode build -target cmTryCompileExec -buildstyle
Development
xcodebuild: error: option '-buildstyle' is no longer supported
Please help me to solve this.I need to install mysql client library using cmake.I'm using xcode 4.3. |
|
|
|
(0028873)
|
|
David Cole
|
|
2012-03-08 23:10
|
|
|
|
|
(0028916)
|
|
David Cole
|
|
2012-03-14 10:06
|
|
|
|
|
(0032041)
|
|
Robert Maynard
|
|
2013-01-09 10:56
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
xcode43.patch (1,554) 2012-02-20 12:13