I dread backwards compatibility. I dread it because it means that for every product that I need to keep backwards compatible, the testing burden is at least twice as big. The math is simple: testing on two major OS versions and two processor types can be as much as 4 times of stuff I'd rather not be doing.
The last time I had to maintain a product with backwards compatibility, this is what I used to do:
- Build then copy application to test machine.
- Get it to fail. This is the one part where I don't have to work very hard.
- Try to fix while scratching head then proceed to littering print statements all over the code.
- Go back to step 1.
You can make this process a little less sucky by configuring Xcode to copy after each build, or by mounting a share so that there's no copying at all. But in the end, debugging with print statements alone is limiting and time consuming. There has to be a better way, right?
The better way turns out to be handsomely better and it's called remote debugging. A remote debugger is usually used for kernel hacking or for developing full-screen applications such as games, but it's quite handy for fixing backward compatibility problems—especially if your app no longer builds on Tiger.
With remote debugging, I can code in Xcode 3—my new favorite IDE—then just hit command-Y. It works as any great software should. Like magic. The application launches on the test machine and you're off debugging as if it were running locally. You can set breakpoints, examine variables and stack traces, fix and continue, or whatever else that gdb can do. There's no longer a cycle of doom, and as a result, I'm a much happier person.
There are just 3 things you need to do to get stress free debugging on older systems with Xcode:
- Set up password-less ssh for logging into your test machine.
- Share the build directory in a way that both machines can access it through the same path
- Configure a new executable in Xcode for remote debugging.
The Xcode User Guide does a fine job of explaining these steps succinctly.
Xcode User Guide — Debugging Programs Remotely
Some additional tips:
1. If your test machine has a different kind of processor, duplicate your Debug build configuration and set it up to build a universal binary.
2. Use "DWARF with dSYM File" as your debug metadata format. With the other two options, breakpoints set through the Xcode UI didn't work for me.
Comments
Imagine if could remotely debug your app in a virtual machine running on your own box! Imagine if you could automate all this - building, copying binaries to a bunch of VMs, running tests against all VMs, copying results back to your system and shutting down the VMs. How cool would that be! Well, it is possible! In fact, some people are already doing all that, just not on the Mac. Let's hope Apple realizes the possibilities and changes their stance on virtualization soon.
I agree that having Mac OS X run under virtual machines will make testing easier. One can only hope that Apple is moving in that direction. I doubt things will change any time soon though, because Apple makes money by selling hardware. You are allowed to run Leopard Server in a virtual machine now, but that's a completely different market where Apple could increase market share by allowing it.
License issues aside, to test on PPC architecture, one would need an emulator type of virtual machine. With PPC going the way of the dodo, I don't think anyone will be bringing a usable solution to market. We're stuck with keeping an old PPC machine around for a few years yet.
Thanks for the tip! I never thought of using remote debugging for this task. Should make things really easier.
One question (maybe you've already tested this): May it be even possible to test the PPC version of an app remotely on an Intel machine by compiling just the PPC version and using the Intel machine's Rosetta engine?
My main computer is one of these "old PPC machines" (well in fact it isn't really THAT old!) and my secondary computer is an Intel MacBook. So if the remote PPC testing would work with Rosetta on the Intel machine I'd only have to have a Tiger partition on the MacBook and use this for all Tiger compatibility tests (both Intel and PPC).
Hi Eberhard. I hadn't thought of taking it that one step further since my test mule is a PPC machine. I generally don't test release candidates with Rosetta because I want to test on the real thing, but I'd be interested in hearing how this goes for you.
Post new comment