These aren’t just templates, though. See the README.txt.
As it implies, the project-tool.py script is used to effectively convert between Xcode templates and buildable projects. That is, you can create a project that builds/runs like a regular Xcode project, and then easily turn it into a template with the invocation of a simple command line like this:
./project-tool --help
Usage: project-tool.py [options]
Copies tree of templates or projects from to .
Before copying, it cleans up by removing various bits of garbage.
After copying, it transforms by replacing strings with their Xcode
template counterparts.
The reverse flag can be used to reverse this process; turning an Xcode
template into a working project.
Options:
--version show program's version number and exit
-h, --help show this help message and exit
-v, --verbose verbose
-k, --kill-dest erase (no warning)
-r, --reverse reverse transformation (template -> editable project)
-w, --working try to make destination into a working project
-n, --nib rewrite NIB files to 10.5 text-only format
-t TEMPLATEFILE, --template=TEMPLATEFILE
path to TemplateInfo.plist that should be used during
conversion
Nothing remotely Python specific about it. And, as some have noticed, the PyObjC Cocoa templates leverage the new Interface Builder file format (xib) such that all kinds of substitutions happen in the templated interfaces, too. As in: No more MyDocument ever again.
Beyond fixing a boatload of bugs and numerous performance improvements, Xcode 2.3 adds DWARF as a native symbol format. DWARF yields a significantly higher fidelity debugging experience, especially for complex C++ code, while also reducing the memory requirements of the linker.
Xcode 2.3 also includes a new distributed build subsystem called Dedicated Network Builds. The preferences pane is a bit fragile — don’t poke at it too hard — but the underlying technology is some neat stuff.
While DistCC remains as the solution of choice for ad-hoc builds on small networks, Dedicated Network Builds [DNB] focuses on accelerating large projects where a farm of machines can be dedicated as builders. In particular, DNB shines with large C++ projects.
Behind the scenes, DNB distributes compilation jobs from your local machine — the recruiter — to the builder machines — the volunteers — using a set of daemons to connect everything together. On the recruiter, a daemon monitors the filesystem to ensure that changes made to the filesystem will cause the remote volunteer caches to be invalidated in an appropriately minimalist fashion.
The volunteers execute the jobs against a mirrored copy of the recruiter’s local filesystem, source, headers, compiler and all. As such, the only dependency between your local machine and the builders is that they are both the same architecture (ppc or i386) and they are running very close to the same version of Mac OS X (i.e. 10.4.5 will be compatible with 10.4.6, but not 10.3.9).
A great deal of effort went into ensuring that cache management wouldn’t swamp the recruiter’s network connection. There is still a hefty cache warmup hit, but the volunteers have the ability to resolve cache misses amongst themselves as well as resolving cache misses against their own local filesystem, when possible.
As one can imagine, there is considerably more to this technology than is described above.
Chris Hanson and I both intended to write something like this someday. Now we don’t have to.
Go read this article about unit testing and code coverage. Specifically, Chris gives detailed instructions on how to integrate gcov based code coverage into Xcode while also leveraging Xcode’s support for unit testing.
Excellent article. Thanks for writing it, Chris. I hope you don’t mind if I file a couple of bugs against Xcode to remind us to integrate something like what you have done sometime in the future.
One very important feature of the advanced breakpoints found within Xcode is the ability to cause something to happen in the debugger — play a sound, print some data, run some AppleScript or invoke a shell script — without interrupting the application being debugged beyond stopping it briefly to take whatever action is specified in the breakpoint.
For debugging stuff like drag-n-drop, mouse tracking, and other human-computer-interaction related functionality, being able to break, take action, and continue the application without de-activating the application or otherwise messing with the context of event processing is absolutely critical.
In modern applications, the challenges of debugging are often not about which line of code is broken, but a matter of figuring out which of the 100,000 executions of a particular line of code is broken. Worse, the line of code is generally going to be invoked along one of many paths, often further convoluted by the code’s presence within a class hierarchy such that invocation is determined by state or customization applied by subclasses.
printf style debugging is often derided as an amateurish approach to figuring out what is going on. And it does suck. But it is often the only way to really figure out what is going on.
Until now. I’m finding that I will configure a breakpoint to log-and-continue. Once I figure out what offensive value is at the root of a problem, I can easily configure the breakpoint to no longer continue and to only stop when that value is present.
End result; no more stop/print/continue by hand with the debugger constantly futzing with the event processing context of the application.
We have a bunch of open positions within the Xcode team. If you or anyone you know is interested, has the skills, and wants to work at a truly awesome company (seriously — working at Apple is a blast), please send a resume/CV my way and apply for the job through the official channels which can be found by clicking the links below.
The list with very brief descriptions. Click through for more information.
2374092: Build Systems Engineer Focused on improving the build system within Xcode. This is not about building Xcode itself, but about refining the code that is run when a developer hits the Build button while running Xcode.
2371488: Xcode Engineer — Xcode UI The Xcode team is seeking an experienced engineer with excellent end user application human interface design skills to conceive, design and develop future enhancements to Xcode and its supporting tools.
The following isn’t with the Xcode team, but may be of interest to folks interest in contributing to development tools.
Within Xcode projects, every file or resource has a reference that instructs Xcode how to find the file. This includes files, resources, build products, dynamic libraries and everything else in the project.
These references are both extremely powerful and quite easy to configure incorrectly. Any resource reference can be either via a relative or absolute path. If relative, it can be relative to one of several locations including the project, the enclosing group, or the build directory.
Now, Xcode also has a very useful feature that allows you to specify a location into which all build products and intermediate products will be written. First and foremost, this will eliminate the noise of the build directory from your workarea. No more “? build” noise from CVS or Subversion. If you point it to the fastest hard drive on your system, you will also gain the advantage of all the intermediate and final products being written to and read from that fast device. If you have a boatload of RAM, create a RAM drive and eliminate a huge chunk of disk I/O from the build process. If using FileVault, moving the build directories will eliminate the overhead of encrypting the files created during the build of the project (with the obvious security sacrifice).
Just make sure you get the resource references correct. In particular, If you have multiple targets and then have a copy files build phase that copies those targets’ products into the product of some other target, make sure you use a build directory relative reference.
A project relative reference will work, but only on your system and only if your build directory never moves relative to your project directory.
And that is the real challenge to resource references. Misconfigured references will work on your machine the first time you set them, but will fail if used in an environment without exactly the same set of paths.
To help minimize the problem:
Use Xcode’s preferences to set the intermediate and final build product directories to some place other than the project. Don’t use the same path. I have often set the path to /tmp/build-bbum/intermediate and /tmp/build-bbum/products respectively. This also guarantees that the projects will be rebuilt after any reboot. Occasional clean rebuilds often seem to clean up weird issues.
Create a second user account on your system and use Fast User Switching to occasionally bop over, update a workarea and build the project. This will also rapidly pick up revision control problems, such as forgetting to add a resource to the repository.
Better yet, keep a workarea on a second machine or have a friend do an update and make sure things still build.
This came up because I had been playing with Growl and had checked out the source because I wanted to fix a few bugs. The CopyFiles build phase in the GrowlHelperApp were project relative, but referred to build products, thus assuming that the build directory is always in the same place relative to the project.
The book is effectively the course materials for the Big Nerd Ranch course of the same name.
Co-authored by Mark Dalrymple and Aaron Hillegass, the book covers many advanced topics in the same clear/concise manner as Aaron’s original Cocoa programming book.
The book is focused on relatively advanced topics such as memory management, the run loop, multiple processes, rendezvous and many other topics. Instead of focusing on the high level details, each topic is investigated from the perspective of documenting the technical details– often non-obvious– through the use of examples, diagrams and discussions.
Two bits that immediately grabbed my attention–and are examples of the approach found in the rest of the book– where the discussion of malloc() behavior and the discussion of the run loop.
In the case of malloc(), the book precisely discusses the fact that malloc() does not necessarily return the number of bytes that you think it does — it often returns more based on certain internal optimizations. The end result is that quite a number of memory size reduction related optimizations are a complete waste of time! Instead, you might be able to consume a few extra bytes by not compressing the data structures and gain raw performance in terms of the # of CPU cycles needed to access the data.
The discussion of the run loop was also of great interest. It clearly diagrams the run loop and the exact point during the run loop — both CFRunLoop and NSRunLoop — that the various events and timers will be handled.
Excellent, excellent stuff.
The $100 price tag is a bit higher than most developer books, but the content is of an advanced and highly refined nature. $100 is a heck of a lot cheaper than $3,500 — the entrance fee to the class for which the book was written.
Big Nerd Ranch has also made a set of resources and forums available online.
