« Sundown | Main | Look, Ma. No framework! »
May 16, 2007
Fail Faster
The default Cocoa Application project in Xcode includes a target with a set of build phases. Here's what it looks like:
Notice that Copy Bundle Resources happens before Compile Sources and Link Binary With Libraries. This means that every time you build, before the compiler or the linker see anything, Xcode spends time copying things like nib files and images into the built product.
If you have a large app, this list of resources to copy can be quite long. Everytime you make a source change and hit command-Y to compile and relaunch your app, it has to run through Copy Bundle Resources again, and then it tries to compile. That's fine. It needs to do that. What's the big deal?
The big deal is that if you're writing a bunch of new code or manually refactoring some older code and you have syntax errors, say, a missing semicolon, a typo in a class name, or a missing #import, the compiler is going to complain and halt your build. If you forget to add a reference to a framework or a library, the linker will complain and halt your build. But it's going to halt your build after copying bundle resources, things that the compiler and linker pretty much don't care about.
In Sandvox's case, there are nearly 200 different resources to copy during a build, and that's not even counting the plugins and frameworks that ship with the app. Doing this over and over again during the course of a day adds up. That's time we can reclaim.
Whenever I make a new project now, I open up the target(s) and move Copy Bundle Resources below Link Binary With Libraries.
This makes sure that the first thing Xcode does is build my code. If it builds, then it can go on and flesh out the rest of the .app. If it's not going to build, I want to know right away so I can spot the problem, fix it, and get back to work.
So I say, move that build phase!, and save yourself some time.
Posted by ttalbot at May 16, 2007 4:25 PM
Trackback Pings
TrackBack URL for this entry:
http://mt.talbotlucas.org/cgi-bin/mt/mt-tb.cgi/287
Listed below are links to weblogs that reference Fail Faster:
» Failed Slower from Lap Cat Software Blog
Normally I refrain from linking to other blog posts. I don’t really consider myself to be part of the blogosphere. (We are the blogocube. We will add your biological and technological distinctiveness to our own. Bring your own beer.) Instead, I f... [Read More]
Tracked on May 19, 2007 1:05 PM
Comments
I suggest that you make a backup of your Xcode project templates and then edit the ones you use. This saves you having to make this change for every new project, since it will already be set that way from the project template. The templates are in /Library/Application\ Support/Apple/Developer\ Tools/Project\ Templates.
Also, I just use ⌘R to Build and Run. Xcode will fire up the Debugger for you if your app crashes; when it doesn't, you've said the invocation of the Debugger (which takes over a second to launch even on my Mac Pro). I have a fuller list of the Build and foo key commands on my own blog.
Posted by: Peter Hosey at May 17, 2007 2:40 PM
A better solution would probably to create your copy of the templates in ~/Library/Application\ Support/Apple/Developer\ Tools/Project\ Templates -- you can make the subfolders' names start with a space or so to get them to be at the top of the list of files in Xcode, but that way you don't need to backup or change any Apple-supplied stuff.
Using Cmd-R is a handy trick, though occasionally the debugger takes so long to load that the system kills your app before the debugger's finished. So don't throw away that "Build and Debug" menu item yet.
Posted by: Uli Kusterer at May 20, 2007 6:12 AM