As some of the readers of this blog may have noticed, we posted the Linux version of our product yesterday, joining the Windows version we originally released.

The product was originally developed under Linux, so it would have made sense to post that one first — except that we had no experience packaging things for Linux, and plenty in packaging them for Windows. Under Windows, it’s a simple and well-known process: pick your installer (we use Inno Setup), configure it, and tell it to create the installer. It took several hours to work out all the details, because we weren’t familiar with Inno Setup before we started, but the basic idea was well understood.

Under Linux, the process should have been equally simple. I expected the hardest part to be figuring out exactly what packages it had dependencies on, but as it turns out, that wasn’t too difficult:

• set up a virtual machine with a fresh copy of your target Linux OS;
• create a snapshot of the virtual machine, so that you can easily get back to the fresh copy later;
• try to run the compiled program, and see what file it complains that it can’t load;
• type the filename and the name of the OS into Google to figure out what package it belongs to;
• install that package;
• lather, rinse, repeat, until the program runs;
• restore the original snapshot for later testing.

No, the hardest part was finding accurate information on the steps needed to package the program, and to compile a 32-bit version on our 64-bit system. There’s plenty of information out there on both subjects, but it’s outdated and/or contradictory, with no way to tell which method was better or why, or even which one actually still works. We even ended up having to dig into the source code for the Ubuntu Software Center to finally figure out why it was claiming that our program had to be run from the command line.

The method we settled on for the packaging uses a program that was apparently designed for creating fake dependencies. It seems to work, and by that point I’d had enough; we’d been working on it for several days, so we left it at that. Maybe we’ll go back and revisit the problem at some point, after we’ve had some experience with it.

We’re just getting started on the Mac port. The language and libraries we’ve used were deliberately chosen for cross-platform compatibility, so it shouldn’t be too much work to finish it… the operative word being shouldn’t, we’ll see. I’ve signed us up as an Apple developer and picked up the “Xcode” packages, we’ll see how they like our code later today.

Wish us luck! 🙂