Okay, I understand - XCode, Universals, and Version Control

Originally published: Monday, August 21, 2006

Will Shipley of Delicious Monster argued at a group discussion at Adler Planetarium that developers should avoid using their own custom frameworks, and harness the power of version control instead. To some extent, this didn’t go down all that well. As someone who was saw the discussion online after the fact, I was left a little perplexed, but then I do consider myself an amateur. After all, frameworks are handy ways on reusing code, and how would a version control system going to help me reuse code effectively?

Enter my work to port my applications to Universal binary (ppc/intel binaries). I’ve had to go back and retouch all my frameworks, and figure out how to build universal binaries of the open source code I use. The universal open source code began to show me the Will Shipley light...

Usually, open source code compiles easily; run ./configure, and make. With universal code, you have to do a bit more than that, depending on the project. So, it was time to get the open source in a local version control repository. The problem is, of course, at this point I now had about five separate version controlled projects. What I typically did before now is check out and compile each project manually. The problem with this is the code can easily go stale and I can make mistakes easily. Furthermore, it becomes a pain if I need to switch computers, which happens more often when I travel, and I have to go through that entire process again.

Enter subversion. Subversion is my preferred version control system. Of the many things in subversion I don’t know, the svn:externals property is one of those things that would have made life much easier. By setting the svn:externals properties, subversion can go out to other repositories or other places within the same repository and bring them into your project hierarchy. So, all those frameworks and open source projects can become a part of my main project fairly easily. Then it’s just a matter of making my main project dependent on those sub projects. No tedious copying, and no working builds going out of date.

So, now that I can do all this with libraries and frameworks, can I get rid of my frameworks?? As it turns out, I can, in theory, get rid of one of them (well, actually all of them, but let’s not get greedy), although I haven’t as of yet. All it takes is reorganizing my existing framework repository to just include the files, not xcode project, and check them out within another project. Then, they act just like regular files I can add to a project - and updating as needed!

So, now that I see Mr. Shipley’s point and how it can be done, will I take his advice? Time will tell.