Archive for December, 2004

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.

While doing a google search, I stumbled across Dethe Elza’s Living Code site.

Dethe’s weblog documents his work with PyGame, PyObjC and Mac OS X.

Very interesting stuff. Dethe has abandoned Interface Builder in favor of Renaissance for UI generation.

I don’t agree entirely with his reasons for not using Interface Builder. However, I do find Renaissance to be quite interesting technology and Dethe’s weblog reads as a good tutorial on using Renaissance and Cocoa via Python/PyObjC.

Subscribed.

There is also a Living Code SourceForge project that contains all of the examples and source from Dethe’s site.

Bob Ippolito (whose blog is currently down) refactored the PyObjC disutils recipe (the setup.py script) such that it uses his py2app to automatically package the build product of PyObjC into multiple Mac OS X packages contained in a single mpkg. End result; you can easily install PyObjC and you can select a subset of the packages to install, as well.

py2app also performs dependency analysis such that the resulting product (not just a package) includes all of the dependencies required by the project.

And it does this automatically for any python project that uses disutils for packaging (which any modern python package should).

I dropped a current build of PyObjC and a new build of the Python Readline support for Mac OS X onto my .mac file download page.

I just finished Digital Fortress by Dan Brown. Same guy who wrote Da Vinci Code.

The book is a techno-thriller set in the NSA and centered around cryptography.

It sucks. Awful. Barely good enough to light a charcoal grill.

What kills it isn’t the writing or, even, the story line, but the technical details surrounding the NSA, cryptography, computer security, and related technology.

I like techno-thrillers (along with many other genres) and can overlook the occasional bit of techno-stupidity in an otherwise well told tale.

Digital Fortress is just too technically moronic. In particular, the stupidity is at the center of the plot.

How stupid? Passwords in the NSA are only 5 letters… and never have spaces in them but are still super-secure. The NSA uses FTP as a secure means of transferring files. The NSA uses wireless keyboards and allows employees to come and go with equipment at will. Random computer viruses will infect custom system architectures and OSes that exist nowhere else in the world. All of this while portraying the NSA as the most advanced computing center in the world. It was so poorly done that even my Mom saw through it (she is not technically inclined).

Sadly, one of the key characters within plot is an expert in romance languages and that particular angle is played well within the book. But not well enough to overcome the rest of it.

Don’t waste your time on this book.