views:

113

answers:

3

For both iPhone and desktop applications, when you choose "Build and Run" from the Run menu (or press cmd+return), Xcode launches gdb and then runs the application with gdb attached. This allows you to inspect stack state if the program crashes but adds significant overhead to program launch time, which is somewhat useless if your program doesn't crash.

Is there some way to enable the "Build and Run" command to just do a build and run the app externally, without attachment to gdb? I tried Googling and poking around Xcode help but to no avail...

Thanks!

A: 

Switch to the release version of your target?

Azeem.Butt
+1  A: 

Change the Active Configuration to "Release".

Chetan
woah, that brings with it lots of other configuration changes that I do not want to take place. is there not a single build setting that I can change?
lensovet
That is a single build setting. In Xcode 2.1 choose Project > Set Active Build Configuration > Release to change to the release build configuration.
Chetan
that was not my point. you're suggesting i use an axe to clip my fingernails. i prefer to use a pair of clippers. Setting the build configuration to Release will result in *many* build settings getting changed. I don't want or need that.
lensovet
Well, you should not be using the Debug build setting for anything but debugging. If you want a streamlined app that you can release without the GDB overhead, you should set it to Release.I don't think there's any way to Build and Run within Xcode without it loading the programmer into the Xcode debugger (a frontend for GDB). If you want to run your app without loading it into a debugger, you can just run the app from the build/Debug or build/Release folder in Finder.Hope this helps.
Chetan
Right, but that requires you to go out of the Xcode workflow and hop through the Finder. not exactly streamlined.However, I'm more interested in this for iPhone development. I don't have the luxury of using the Finder for that...
lensovet
Well after doing some tinkering and searching of my own, I would conclude that using Build and Run within Xcode launches the Xcode debugger, and there is no way to disable this.
Chetan
There isn't much chance that Apple's going to accept a debug build into the store, so you'd better get over this bizarre phobia of yours.
Azeem.Butt
bizarre phobia? gee you sound like a nice guy. I have no plan of submitting a debug build to the app store; I simply wanted to be able to run debug builds on my phone without having to launch them attached to the debugger every time i did it from within xcode (though I highly doubt apple would do any kind of testing to see whether a build was a "debug" version or not). I don't see why this is so "unreasonable."of course none of this would be an issue if the simulator supported the modern runtime, but that's for a different story.
lensovet
and, is it turns out, all the namecalling is useless anyway.changing the configuration to Release for an iPhone app *still launches the debugger*. time to file a Radar I guess.
lensovet
As I said:"I would conclude that using Build and Run within Xcode launches the Xcode debugger, and there is no way to disable this."The only way to run your app without the debugger is to run it on its own outside of Xcode. Pretty stupid, I agree.
Chetan
see correct answer above
lensovet
+1  A: 

The correct answer is to choose Project > Edit Active Executable and in the Debugging tab

alt text

Uncheck "Auto-attach debugger on crash." When this is checked, Xcode starts your app under gdb even when breakpoints are disabled, even when the Release configuration is built, so that if your app crashes you can see the backtrace in the debugger rather than in CrashTracer. If you uncheck this, it doesn't start in gdb unless you Debug.

cdespinosa
this manages to crash the debugger when used with iPhone OS apps. Haven't tried with Mac OS X apps yet...
lensovet
Tested on Mac OS X app and works as described. Of course, the funny thing is that I mainly care about this for iPhone, since it is in that case that the debugger adds the most overhead. Oh well, looks like this is the right answer.
lensovet