13
votes

I'm building an iOS static library (as per https://github.com/jverkoey/iOS-Framework). I depend on SBJson and AFNetworking. I would like to include these libraries to avoid version issues and for installation simplicity; to do so, I need to prefix these libraries to avoid naming conflicts.

How can I prefix other static libraries in a simple way?

Ideally, it would be part of my build process. Less ideally, but acceptable, are tips on how to refactor and rename in a sane manner.

1
I will also be using CocoaPods so they handle the dependencies for those who have it, but would like to be able to distribute a non-CocoaPods framework.Liyan Chang
One word: DONT! There is nothing wrong in having external dependancies.Till
It seems to me that alot of frameworks do this to make installation easier. One example: Dropbox renamed SBJson to DBJson.Liyan Chang
There isn't an easy way to do it. A careful find and replace has worked in the past for me.kels

1 Answers

21
votes

The only safe solution (other than not doing this at all) is to build any dependencies with a prefix on all symbols.

The easiest method of prefixing is the classic "find-and-replace". This is error-prone, so it's a good idea to hit the .a with nm -a and scour the results for any non-prefixed symbols.

A second, much safer method is to use a two-pass compilation process.

  • The first pass builds the dependent project and runs nm to dump all symbols into a header file.
  • The second pass builds the dependent project again, but this time with the generated prefix header file imported in the precompiled header. This prefix header must be used anywhere you reference symbols from the dependency in your framework in order to properly refer to the renamed symbols.

For reference, we use this with Nimbus to generate the Nimbus prefix headers: https://github.com/jverkoey/nimbus/blob/master/scripts/generate_namespace_header

This allows you to distribute a .framework with a prefixed version of Nimbus embedded.

You can now link the resulting .a into your framework and safely avoid any linker conflicts when a third party developer inevitably links their own version of the dependency into their project.