The best way to package iPhone/iPad static libraries?

Question

Hi everyone,

I have a couple of static Phone/iPad libraries I an working on. The problem I am looking for advise on is the best way to package the libraries. My objective is to make it easy to use the libraries in other projects and include the correct one in a build with minimal problems.

To make it more interesting I currently build 4 versions of each library as follows

• armv6/armv7 release (devices)
• i386 release (simulator)
• armv6/armv7 debug (devices)
• i386 debug (simulator)

The difference between the release and debug versions is that the debug versions contain a lot of NSLog(...) code which enables people to see whats going on internally as an aid to debugging.

Currently when I build the whole projects I arrange the libraries into two directories like this:

release
    lib-device.a
    lib-simulator.a
debug
    lib-device.a
    lib-simulator.a

This works ok except that when include in projects, both paths are added to the library search path and switching a target from one to the other is a pain. Or alternatively I end up with two targets.

The alternative I am thinking of is to change the directories like this:

release
    device
        lib.a
    simulator
        lib.a
debug
    device
        lib.a
    simulator
        lib.a

In playing with XCode is appears that all xcode uses the lbrary references of a project for is to get the name of the library file, which it then looks up in the library paths. Thus by parameterising the library path with the current built type and target device, I can effectively auto switch.

What do you guys think? Is there a better way to do this?

ciao Derek

Answer 1

Some time ago i wrote this post:

Managing static versioned libraries in OS X

The basic idea was to build a directory tree containing different library versions and switch between them, but maybe you can adapt the idea to your problem.

Answer 2

After much playing around I'm now building static frameworks instead. This makes life much easier all around.

I've now come up with a set of scripts that for me, do the a similar set of functions to those done by a maven build. they clean, compile, document and package the API.