Dear Steve Jobs:
It’s nice when a topic for a blog rant presents itself, and you don’t have to go finding it.
Today’s jobs included getting the OS X version of the beta packaged for release. Since we use all cross-platform libraries, adhere strictly to the ANSI C++ standards, don’t use Microsoft-specific extensions, and have generally made life as easy as possible for ourselves, this should be easy. Wrong. In order to actually get an OS X application in distributable format, you have to perform what is commonly known as the “application packaging song and dance.” In particular, you have to:
– create a new directory for your application (in our case, “dredmor.app”)
– Fill it with a Content folder.
– Inside the Content folder, put in a directory called Frameworks. Copy all your .dylib files from your computer’s /usr/local/lib directory that your project uses, and presumably their dependencies, into the Content/Frameworks folder.
– Run, I kid you not, a magical command-line application on all your .dylib files. The syntax for this is vague and arcane. I refer, of course, to install_name_tool. You will need a shell script to do this for you, and you will need to do this every time you update, or add, libraries to your project. Actually finding out what libraries you use involves running the otool tool.
– Determine what magical linker settings you need to use in order to make everything work.
– Figure out the next magical mystery thing that goes horribly wrong for no good reason, such as how to use Installer (which is actually a software package originally developed by NeXT back in the late 80’s.)
I imagine XCode does some of this for you, but XCode is so awful that I prefer not to use it, relying instead on emacs. It is also worth noting that I know all of this because I worked on a project with Ryan C. Gordon, and was able to poke his brain for advice every time OS X threw something wacky and undocumented at me. If I was forced to do this without patient handholding from the best of the best, I would likely have thrown my computer out the window. Being a Mac Pro, the sharp handles and bare metal would have sliced somebody’s head open before crushing them under the weight of its ridiculous quantities of memory.
As it stands, I have a build that runs on my OS X development box, but I’m not sure why it’s not running on David’s Macbook Pro. Both machines are Intel Core Duo machines, but when I try to run Dredmor in his Macbook I am presented with a message telling me that the application “is not supported on this architecture.” I could understand that message if it was a PPC that he was trying to run it on, but the Hardware Overview says it’s a Core Duo. My best guess is that since I built on OS X 10.6, it’s not very happy about this, and wants me to use Magical Switches in order to build a binary that can run on OS X 10.5. Either that, or I actually have to downgrade my entire operating system in order to produce a compatible binary. Again, XCode probably has a setting for this, but this doesn’t help me; I’m using a makefile because, again, XCode is atrocious. I suspect tomorrow I either get to A) launch XCode, write an XCode project, figure out what compiler and linker switches it passes the compiler and linker to produce a backwards-compatible EXE and then steal them, or B) just ask Ryan what the heck’s going on. It may be that I’m wrong, in which case I get to *guess* what possible architectural difference this error message could be referring to.
It is worth noting that the #2 search result for install_name_tool on the web is from Trolltech’s website. Since Trolltech make Qt, they have to explain to their users how to actually distribute software that works on everybody’s computer. This isn’t an issue for Apple. I don’t know why.
Apple, get your act together. This is atrocious. The Linux camp has an excuse, because it’s so fragmented that getting anything done is a nightmare that involves waking up with Alan Cox standing above your bed screaming at you in Welsh while holding a bloody human torso, but I fail to understand how a company that prides itself on producing beautiful, well-thought out works of art and design can then manage to make deploying software such a nightmare.
First, document your darned toolchain from the perspective of both a Unix-based and an XCode-based developer. The Unix documentation is sorely lacking.
Second, fix XCode. By “Fix XCode”, I mean “make it more like Visual Studio.” You don’t compete with Photoshop by trying to build an entirely new user interface for it where everything is a draggable window; that’s how you get the GIMP. Nobody uses the GIMP.
Third, build a tool to automate the deployment process from me so that I don’t have to run my own shell scripts.
Fourth, provide me with a useful debug message that actually explains the nature of the problem with my application when I try to run it on somebody else’s computer, rather than simply saying “This won’t work on this architecture.” What is an architecture, anyway?
Fifth, and last, figure out exactly what you mean by Framework. As it stands, Framework comes across as a meaningless nonsense word. I’m not sure, for instance, why Cocoa is a framework when a Framework is just supposed to be a hierarchical collection of resources, and Cocoa sure seems like a library to me. In fact, your documentation says that a Framework is both “a hierarchical collection of resources” and “a static or dynamic library.”
I hope that if you stop abusing me, we can have a fruitful and inspiring relationship. While you’re at it, do something about that “open computing” stuff you were so big on back in the eighties.
Yours,
Nicholas
PS. I am not saying that Win32 deployment is better; in fact, if you try to use the SxS model you will soon find yourself in a quagmire from which none can escape. This is why Dredmor bypasses SxS entirely.
