Each C/C++ library has some amount of headers that should be used with that library. And if you're use more than 1-2 libraries, custom header paths is kind of headache.
So I thought: is there a way to compile C libraries as frameworks. Static library + headers + versioning.
I found in XCode template for Cocoa framework but nothing about iPhone framework building. This simple step could allow developers to build and share between each other frameworks with some interesting code.
Also it would be great to use libpng, libjpeg and other libraries packaged as frameworks.
I won't use dynamic libraries in those frameworks. Only static version will be present.
I combined techniques I found here and here into my open source library here (NOTE - I have since removed the relevant scripts from this project. I have updated the link to point to the last revision that included these techniques.). Think that's basically the solution you're looking for.
Basically, it has a target that will build a fat static library (lipo builds for arm6, arm7 and i386). It has another target that takes that library and builds it into a framework.
There's no reason you can't use the same techniques for a C project. In fact I've started work on porting C the VTD XML parser to an Objective C framework using the same techniques.
Frameworks are basically just bundles of dynamic/shared libraries. Since this is not allowed in the App Store, you have to build static libraries and link them with your App's executable at compile time.
However, to ease the pain a little, you can have a Xcode project for each library and compile each library into a static lib. Another way would be to put all required source files into the main Xcode project and configure it appropriately so it all builds at once (I did this with small libraries like Minizip, for instance).
Hope that helps.
the problem you are trying to make already exists - it's called DLL hell
Best way is to stick with plain old static libraries when making small apps and organizing source/headers structure
Related
I have some source code in C/C++. I have to make static library to use in my iPhone application. is there any third party tool to create static library for armv6/armv7 ?
this link will help you create a static library in xcode ...
http://www.icodeblog.com/2011/04/07/creating-static-libraries-for-ios/
just rename the .m file to .mm file and write your c/c++ implementation code in it....
try it for a small function first and if it works for you can implement all your classes in it...
Please make sure when you try to use this library in any other project in XCODE , only use .mm extension for all your files even the appdelegate... hope this helps.
I would recommend iOS Universal Framework. I have used it to create a number of static frameworks that I link against my application projects. It works like a charm and is really easy to setup - no need to come up with your own complicated shell scripts.
It adds a template for a new target project type, which you can then import and use just like an ordinary Apple framework. I would recommend setting up a workspace containing both the framework project and application project, that way the dependencies are handled automatically by Xcode.
In general, you DO NOT WANT to link to a static lib that is made with another compiler than the one used to compile the lib. Static libs are not really portable between compilers, since static lib formats are not covered by C/C++ standards. Due to name mangling and other formatting differences, you may not be able to link at all, or worse, it seems to work but injects bugs. Worse, if you use the standard library from your compiler in your lib, it will create horrible name collisions when someone links to your lib and they don't use an IDENTICAL version of the standard library!
Publish the lib using the compiler you expect them to be using. And if you must use the standard library, then you have to make sure they have the same version you have. Really, you should just have them compile the lib themselves or prebuild it for each compiler you support. It sucks, but that's the reality of it as it stands today.
I have a project that includes a shared library as source files.
Some of the library classes need the include of some Frameworks (like the known Apple Reachability).
Those Frameworks are not included into the project because I don't use the classes / methods that needs them.
I have a MyStandardLib.h that references all the library headers, and that is included in the.pch on my app.
But...
When building my app, the linker generates link error for those objects I don't use/call in the app So they should logicaly not be linked.
As an example, if I remove from the project the incriminated classes and Frameworks, everything works fine.
If I add the needed Frameworks :
It's crazy to do that for each project because of classes I won't use
It increases my app file size for nothing useful (26 Ko -> 1.2 Mo)
How can I avoid those linker error, and avoid links that should not happen :
keeping my library as is in the project (I don't want a precompiled library)
Not needing to include all those useless Frameworks until I really need them
The reason for those errors are clearly because the frameworks you are including in your project do require those other frameworks (from what you could provide they use: Reachability, the CFNetwork Framework and the CoreLocation Framework)
What is happening is that when the compile links your objects (in the compiler sense of it) it is also looking for objects 'mentioned' in your added frameworks and it is not finding them because they have not been included to your projects.
If you use a Framework A that is linked with Framework B then if you application C uses framework A it also needs framework B because frameworks are not exactly self contained.
If your code compile without those frameworks and your application needs to take low space simply remove them from your Build Phase and you'll be good to go.
However, if it doesn't compile without those frameworks you will have no choice but to include them in your project and, therefore, increasing even more the final space required by your application.
Has anyone had any success in finding a reliable, generalised solution for managing dependencies for iPhone projects? I'm looking to split my iPhone applications up into reusable components and then pull them into projects that require them. I guess I'm looking for a Maven-esque workflow but for Xcode/iPhone projects. I've tried a number of things so far such as:
I've created a Maven plugin for iPhone applications which automates the building and signing of the applications but I constantly feel like I'm fighting against Maven to get this to work and it is altogether pretty messy. I'd rather not use this unless there are no other options.
I have also tried using static libraries to package the code up to re use but the problem with this is that I'd also like to include reusable XIBs and images in my projects and these cannot be included in the static library for redistribution. They are great for code but I'd like to have one system that does everything rather than different dependency management systems for different types of dependency.
At the moment I've settled on using the version control system to do my dependencies for me. In this case I'm using SVN externals to load the dependencies into the workspace when I checkout the project.
Does anyone have any ideas as to what I could do?
Update
I'm now using CocoaPods to perform this task.
The way I've done it in the past is as follows:
Static Library for shared code
Bundle for Images / Data Files / Etc (Non Code)
By doing this, you only ever have to worry about updating the project that manages your static library / bundle and not the applications that use them.
The key thing to creating a bundle, is that Bundles are not listed under iOS when adding a new target to a project. Instead they are listed under Mac OS X. Don't worry, it works great.
Once you've created your Bundle and Static Library targets, you'll need to get those into your application:
Add the Static Library under Link Binary With Libraries (Xcode 4)
Add the Bundle under Copy Bundle Resources (Xcode 4)
The final thing to keep in mind is that when you want to load resources from the newly created bundle you need to do something like the following if you were going to load an image:
UIImage *myImage = [UIImage imageNamed:#"YourBundle.bundle/MyImage.png"];
With Static Libraries, you can distribute the XIB's/Images/Strings in a Bundle Folder which can be imported easily. It is the easiest approach I've found for distributing dependencies short of distributing the actual Code/Xcode Project
I've build a static library working nice in a Cocoa Touch environment. Now I'd like to compile it also for Cocoa.. Can I have a single XCode project with different sdk targets? Is there some resource out there able to give hints about best the practices in this (and other) sense?
This last two months I have been working on exactly this task ( cross compiling static library for iPhone/Android/Mac OS/Linux/Windows...
It is certainly possible, a nice way, is adding an external xcode project as a target to your first xcode project. So you create a new "Active Configuration" for Mac OS X, iPhone and other platforms that you want to support.
Here, you can find a good tutorial about how to use a secondary Xcode project as a target of your main project to build a static library. It's a cool way because if you debug for example you still have all the symbols of the library, etc.
It can be done but it requires some manual tweaking of the build.
Start with the Xcode Build System Guide.
As an informal way of accomplishing this, you can create two separate projects and add references for exact same set of library source files to each project. Set one project to compile for Cocoa-Touch and the other for Cocoa. If both projects reference the same files, changes made in one project will be automatically reflected in the other. (If you have both projects open, Xcode will complain that the file has been changed by another app but otherwise it won't notice.)
I have a utility class that I continually dump new methods in. I add it to every project and just park methods as I need it. The new methods show up in old projects because the source files are shared across all the projects.
I'm trying to write an SSH client for the iPhone, and I'd like to use the libssh2 open source library to do so. It's written in C.
How should I include this C library for my iPhone app? Should I compile it into some binary that I include into the my app, or do I add all the source to my project and try to compile it along with the rest of my app?
I'm interpretting this question as:
"Should I compile the C library code once, and include the binary library in my project? Or should I include all the source and compile it every time I build my app?"
It depends. One of the projects I work one depends on several external libraries. Basically, we have a simple rule:
Do you think you will need to change code in the C library often?
If you will be changing the code, or updating versions often, include the source and build it with the rest of your project.
If you're not going to change the code often or at all, it might make sense to just include the pre-built binary in your project.
Depending on the size of the library, you may want to set it up as a distinct target in your project, or for even more flexibility, as a sub-project of your main project.
If I was in your place, I would build libssh2 ahead of time and just include the binary library in my iPhone project. I would still keep the libssh2 source around, of course, in case it does need to be re-built down the road.
I have an iPhone app that is 90% c. I have had no problem adding 3rd party sources to my project and compiling. I am using Lua, zLib, and libpng with no modifications. I've also included standard libraries like unistd and libgen and they just workâ˘
The Three20 iPhone library has a great howto on adding their library to your xcode project. Give that a shot.
I think you will find in the long run you will be better off building it into a standalone library and linking it with your application. This makes it easier to integrate into future apps. Another benefit is that it encourages code separation. If you feel pretty confident with the library, you can link your debug exe to the release build of the library and get some extra performance.
I can't really think of any downsides to creating a library, after the initial cost of setting it up, and having an extra project to modify if you have some changes that need to be made to all your projects. Even if you don't know how to make a library for the iPhone, this is a good excuse to learn.
Just adding the source to you project should work fine as well.