Re: xcodebuilds fails where Xcode.app succeeds; source tree problem
Re: xcodebuilds fails where Xcode.app succeeds; source tree problem
- Subject: Re: xcodebuilds fails where Xcode.app succeeds; source tree problem
- From: Chris Espinosa <email@hidden>
- Date: Wed, 3 Mar 2010 11:19:36 -0800
On Mar 3, 2010, at 10:42 AM, Sean McBride wrote:
> On 3/3/10 10:37 AM, Chris Espinosa said:
>
>> Oh, I bet you've run into one of the oldest and weirdest Xcode bugs that
>> we've not been able to fix.
>>
>> rm ~/Library/Preferences/xcodebuild
>>
>> See if that does it. Then I'll explain.
>
> Success! I owe you more beer. :) I am curious to hear your explanation...
Xcode.app and xccodebuild share common frameworks in /Developer/PrivateFrameworks. Code in those frameworks reads and writes user defaults that affect both the command-line tool and the IDE. The nominal workflow is to launch the IDE, and default values get written to com.apple.Xcode.plist and are used by both the IDE and the tool.
But if you have a machine on which Xcode.app has never been launched (or you wiped com.apple.Xcode.plist), and you run xcodebuild without running Xcode.app first, NSUserDefaults will use the tool's bundle identifier (xcodebuild) as the bundle identifier for writing defaults, and will write a stunted user defaults file for the tool which will then shadow com.apple.Xcode.plist. So no matter what you set in preferences in the IDE, the tool will always get its shortened and ineffectual copy of user defaults, until you delete that file and let the IDE's user defaults propagate to the tool.
Chris _______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden