Short version of the question:
So basically what I'm looking to do is to take an existing library written in C (https://github.com/lsalzman/enet) and turn it into a static library for iOS.
I am just looking for an easy to understand step by step of how to accomplish this in Xcode.
Long version:
I've gone over some tutorials for making a simple static library that's written in Objective-C (http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial), and I generally understand what is happening there, but I'm failing to understand how to do this with existing code written in C.
I think I'm getting close, but I'm not so sure.
- I start out by making a "Cocoa Touch Static Library" project in xcode.
- I add all of the enet .h and .c files
- make sure the enet stuff is in my "User Header Search Paths" in build settings.
- hit build - it compiles!
The generated .a file is 517kb, so I'm pretty sure it's building the enet stuff in at this point.
My problem right now though is that the header file for the library is basically empty:
#import <Foundation/Foundation.h>
@interface enet_ios : NSObject
@end
I'm thinking I either need to write a wrapper in Objective-C that talks to the enet library, or I need to reconfigure my xcode project somehow so that enet.h is the 'entry point' into this library and not xcode's pre-generated .h/.m files. I'm not really sure how to do that, though. Ideally I'd just like to skip any sort of wrapper and use what the enet library is already providing me.
Thanks for taking a look!
Question, are you trying to call the functions using objective c syntax / object orient notation? Then you do need a wrapper object, no way around that.
But if you are fine calling C functions directly, which is completely acceptable in IOS/Objective C, then it is a matter of making sure your header files from the enet library (the ones in the include directory I see in the github link you shared) are also distributed with the static library. This is a limitation of the static library. You can copy them with the *.a, but they must be copied with the static library. This does differ from a Framework, which has included .H and assets, which developers are not easily able to create with Apple's tools for IOS.
I find that library management with Objective C to be painful on its own and static libraries a challenge for this and many other reasons. One more suggestion, definitely more elegant and portable but slightly overkill for personal use, would be building the project as a cocoapod. You can do this by forking the project and converting it to cocopods. There are lots of examples of how the project structure should look on cocopods and other OSS like AFNetworking. This seems to be the defacto standard way people are creating IOS libraries. See http://cocoapods.org/ for more details. This will include the source code as the pod and compiled against the target application.
This is the only way i deal with my own libraries and third party libraries. It has gotten to the point that if the library doesn't use cocoapods, i don't use the library or fork it and do make it a pod myself....
