Much as I love using OSX now, I still miss my Windows development tools. Even though I’ve gotten used to using XCode and related tools now, they still have multiple limitations that really annoy me when I’m trying to get things done.
I mentioned a little while back that I’ve wrestled with Framework versioning and debug / release configurations. I’m not much closer to solving those in any way I feel is elegant, or even adequate. XCode seemingly just doesn’t want you to develop against more than one version or build configuration of a Framework, and if you do, you have to bend over backwards to make it work. In terms of versioning, I’ve reorganised the build setup on OSX now so that both the Ogre framework and Samples share a build location, which allows me to make the framework reference in the Samples relative to the build location, so the Samples project at least can now build independently. I plan on bumping the major version of the Framework in Shoggoth soon so that at runtime, both can co-exist. This solves the problem for the samples, but doesn’t solve it for any other project. For those, I suggest referencing the Framework ‘Relative to Project’ or even ‘Absolute Path’ to ensure they build against the right version.
Debug and release isn’t solved though. Whilst some core Frameworks have debug versions with a _debug suffix akin to using the _d suffix on other platforms, there isn’t a nice way to set up XCode to produce or consume that per build configuration. I.e. it would seem sensible to tell XCode to append _debug to the framework name only in the Debug build configuration - but you can’t. It would also be sensible to tell XCode to look for _debug suffixes when consuming Frameworks only in Debug builds, but you can’t - you can only do it globally. Also, when using many external frameworks you may only want / be able to use debug frameworks for some of those; but again XCode only allows you to tell it to look for the _debug suffix globally. How bloody stupid is that? I can’t help but think that no-one at Apple has really thought this through, since this is incredibly basic build managment stuff.
So, pretty annoying. I’ve been working with PackageMaker recently to get an SDK built for OSX, and have been scripting it so it’s all automated. That went fine for creating the individual packages for components (as you have to do to install things in different locations), but when I came to build the distribution package which wraps them all, it worked fine in the GUI but from the command-line it just fell over. Some hunting in the Apple mailing lists revealed that PackageMaker doesn’t like building distribution packages via the /Developer/Tools/packagemaker alias, you have to use the full /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker path to avoid it crashing - depite the alias working fine for individual packages. Odd, but sure enough that got me past the crash. But then I found that it wasn’t referencing my single packages properly - it gave me a ‘missing size field for ’ for every package and the install fails. More hunting on the Apple mailing lists revealed that PackageManager also can’t handle relative paths when building a distribution package from the command line, you have to use absolute paths. Which is completely useless as I need this to be location independent. Grrr. So now my plan is to set it to absolute and then script a text replacement to the project file before firing it off, to see if that works. Really shouldn’t have to, this is an obvious bug.
It’s nice of Apple to give us free developer tools like this, but by God do they have some nasty rough edges. Here’s hoping that XCode 3 and related tools cleans some of this stuff up.