OS X framework issues - solved

· by Steve · Read in about 3 min · (572 Words)

Ok, so despite not getting a great deal of useful advice on the Apple developer forums about the framework issues I’d encountered, through reading, thinking and discussions with Justin I’ve now changed the Ogre build setup so that it copes with both multiple versions, debug and release configurations and eliminates the issues surrounding where to install frameworks.

The answer was basically pretty simple. Whilst frameworks would lead you to think of Linux centrally located shared libraries on steroids, what with the ability to be Universal (PPC and x86 compatible), in fact in practice they are much better used like the local shared libraries you would use on Windows apps. Whilst frameworks can contain multiple major versions in one central place, which would lead you to believe that that’s how you should try to use them, in practice for an app developer, trying to put things in /Library/Frameworks is a nightmare. For many reasons:

  1. Permissions - the easy one
  2. Versioning - the fact that XCode doesn’t easily allow you to choose what version you link to
  3. Configuration - you can’t have debug and release versions installed at the same time
  4. Installation - it breaks the ‘drag & drop install’ idiom

So, as of the latest CVS, which will become 1.4.5, we’ve dropped the idea of using a shared framework location, and instead frameworks will be assumed to be contained within the application - ie under Foo.app/Contents/Frameworks. In order to resolve the issue that in our samples it would result in frameworks being duplicated a huge number of times, we now use a Run Script phase in the build to symlink frameworks into these locations rather than using the traditional Copy Files build phase. Obviously this won’t work if you then copy the app somewhere else (without also moving the frameworks relative to it) so when making a real deployable application you would obviously use a genuine copy. Because everything is local it also makes simultaneous debug & release configurations easy to support.

So the end result was quite straight forward, albeit rather unintuitive when you read up on the features of Frameworks, which really lead you away from this solution towards a centralised approach, with the way they are presented. Nevertheless, when you look at some other applications, you clearly see that containment is the ‘normal’ way of doing it - yes it means that you duplicate libraries all over the place in the file system if you use several apps that use a single framework, but it’s the only way to get that self-contained, drag & drop application setup that solves all of the issues from UI consistency to version choice and debug/release configuration.

If you update from CVS branch ‘v1-4’ now you’ll get the changes. There’s also a new dependencies package on the Sourceforge page which reorganises where the dependency frameworks go. You’ll need to remove Ogre.framework and the dependency frameworks like Cg.framework from /Library/Frameworks since they now live locally in ogrenew/Dependencies.

Oh, and here’s an odd thing I discovered. If you change the path to an existing external framework in XCode (rather than deleting and re-adding it), make sure you open the Get Info panel on it, and uncheck and recheck the boxes next to the targets using it. If you don’t, you seem to get inexplicable linker errors saying it can’t find the framework - probably a dirty flag issue or something. Puzzled me for a little while anyway.