Upgrading the Omni Frameworks for Xcode 2.1

Last time I talked about the Omni frameworks, it was to warn you to use the .pbproj versions, instead of the more logically-named .xcode versions. That was all I needed to do to make them work with Mac OS X 10.3 “Panther.”

Now we’re up to Mac OS X 10.4 “Tiger” and Xcode 2.1. Is it more complicated this time? You bet.

I use cross-project references to refer to the Omni projects in my own project. Important tip: cross-project references only work in Xcode 2.1 if all projects have been upgraded to 2.1 project format. So I upgraded all three projects. Since I used the new .xcodeproj suffix for the upgraded projects, that meant I had to remove the old project references from my project and add the new ones, which meant I had to re-add all the dependencies and build products for my project’s targets. A bit of a pain.

Once I’d finished that, OmniBase built fine. OmniFoundation did not.

The OmniFoundation project refers to /usr/lib/libbz2.a, which is missing under Tiger, replaced by /usr/lib/libbz2.dylib. I don’t want the project to refer to the dynamic version of the library: that would presumably make it only work under Tiger. I want it to use the static version of the library.

For the C++ standard library, you can switch from the dynamic version (available 10.3.9 and up) to the static version (works in 10.3.8 and lower) by switching compilers. GCC 3.3 uses the static library, GCC 4.0 uses the dynamic library. This is why just changing the SDK from 10.4.0 to 10.3.9 (or even 10.2.8) isn’t enough if you want to support older versions of the OS.

Changing compilers doesn’t help with the bz2 library, however; instead, the SDK is the key here. The full static library is still available on a Tiger system, but not under /usr/lib. Instead, it’s available under /Developer/SDKs/MacOSX10.3.9.sdk/usr/lib. So I changed the project to refer to that.

There were a few other tweaks needed. I went into the OmniFoundation (Framework) JAM-based target and both unchecked the “Treat all warnings as errors” checkbox and, under the Expert View, removed -Werror from the WARNING_CFLAGS setting. Actually, first, I tried going in and fixing all the warnings, but some of them turned out to be quite obscure, so I finally gave up.

I had to follow the same steps for the OmniAppKit (Framework) target in the OmniAppKit project.

Could it be dangerous to let so many warnings go by? Maybe. But I hadn’t changed the code to produce the warnings; instead, they occurred because GCC 4.0 is more strict and produces more warnings than GCC 3.3. Should someone fix them eventually? Yep. For tonight, though, it’s good enough that all the Omni frameworks I have build successfully.

Finally, a note about how Xcode 2.1 builds targets referred to via cross-project references. Before, Xcode would build the targets in other projects without any build style at all. In 2.1, Xcode attempts to match build configuration names. If your project is building with the configuration “Development,” and the other project has a configuration named “Development,” it is used for the other project’s target, too. It’s a very nice improvement.