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.
Related
I've been writing iOS apps for some time now and for this particular project, I decided that I needed a static library for code sharing purposes.
I've followed some tutorials in creating static libraries and everything works perfectly.
Now I wonder, is there any way of versioning the static library?
I couldn't find any files regarding version number in the static library project, nor any good search results (both Google and here) regarding this particular issue.
I think I could create some kind of "fake" Info.plist and store the version info there.
Is that the way of doing it? Any other approaches to the problem?
Edit:
I think I may have not been clear on my purpose:
I have a workspace that has both my library project and related projects using the library, which is imported using the .xcodeproj file, then configured the dependencies so it builds whenever needed.
I just need some way of versioning the library, so that I can include that in some sort of about box, just in case.
I think you should stay away from bundling binary builds of your own code. Unless you're building a really, really, really massive library, you're better off just importing the code in any of your projects, and rebuilding it each time. You can put it in a separate target though, so Xcode doesn't rebuild it all the time.
You might want to write a tool that takes version info in a .plist and writes it out as literal strings defined in a .h file, which you can then include in your own code.
To make it foolproof (avoid mismatch between the header and the library), define a class method like [YourLibraryClass versionString] that returns a NSString with the version number or signature.
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
i want to share some code with other iOS projects. So I create static library.
When I use this library in other projects and use header file from that lib I get an error like No such file and Directory. Can any one tell me fixes of it.
Here I get reference for making static lib
http://www.amateurinmotion.com/articles/2009/02/08/creating-a-static-library-for-iphone.html
I downloaded that sample. It is also not working in my case. So please help me to fix that error.
Thanks in advance
My guess would be because the blog, whilst detailed, is probably a bit old now. Like anything there's a thousand ways to skin a cat.
You can now create frameworks for the iPhone sdk and include both simulator and device versions of the classes. Frameworks have the advantage that they can simply be dragged and dropped on Xcode to include them in a project. In addition I like to store my frameworks in version numbered directories so if I make changes, dependent projects can still use the old ones until I'm ready to update them.
I don't do it, but for the above reasons I'm not sure I'd drag and drop a libs project on a client project. To me the idea of a static framework is that it's independent on it's clients. Dropping it into client projects makes a connection between the two projects that is too tight.
Anyway do some searches on lipo and static frameworks. I also have so scripts in my project at https://github.com/drekka/dUsefulStuff that you mint find useful.
I was always wondering what's up with those Targets? What is it all about? What's the point of that? I never had to fiddle around with them, but obviously I can. Why should I want that, and what can I do with them? What's their purpose?
Each project can build multiple executables or libraries or call out to a makefile or shell script to build "stuff". Each one of these is a Target.
One iPhone project I have includes a separate target for each static library in my home grown SDK and a shell script target to build the Doxygen docs. Another project includes two targets, one for the app as used by general users, one for an administration & management edition.
In the first example, I need to build each library then link all the static libraries into an SDK test application, so my SDK Test App depends on all the library targets (but not the docs, since I don't need to constantly regen them.)
In the second example, the management and the general versions of the app share a considerable amount of code and resources. When I change one, I want to change them both.
The target is something like a "blueprint". It includes rules that tell the compiler what to do, which sources should be compiled, which files should be copied into the application bundle, which libraries should be linked.
If you want to make a Free-Version of your app one way to do so is to add a new target.
Of course you could just duplicate the whole project but then you had to keep those in sync if you change some code. Using a different targets makes this a lot easier.
I realise that the view/controller stuff will be different between Mac and IPhone apps but the model code may well be similar/the same. So whats the best way to organise a project(s) so that the model code is/can be shared?
Copy/paste - just duplicate it and manually keep it in sync
Have 2 xcode projects point at the same workarea - one for Mac and one for IPhone and share the code.
Common library - presumably you can't do this (or can you)
Thanks for any tips.
There are a few ways to do this. The first thing you can do is is create a project that builds as a framework on Mac OS X. Since you cannot use frameworks on iPhone, you can make static library target that contains the same code files. That basically works, but the header paths will be different. If you want the header paths to be the the same (i.e. <Myframework/MyFramework.h>) you will need to modify the the install path of the static library headers so that they are copied into "$SDK_ROOT/usr/local/include/MyFramework", and make sure /usr/local/include is an included header search path. You will then need to install the library and headers into each SDK_ROOT.
I started out doing the above, but I found it to be a royal pain. So I ended up doing something that is a variant of #2. Basically, I get the header paths to be equivalent by making a directory named "Externals" in my iPhone project root, then a directory named with the appropriate name ("MyFramework") in the externals folder. That is the folder I copy I drag the framework files into.Findally I add the Externals folder as a system header path (which is admittedly sort of a gross hack). You need to manually add new files to the iPhone project, but I have found that to be less of a pain the installing static libs into my build root.
I'm not sure if the suggestion from the previous answer would work. If you look at my previous question, you'll see that I've failed to load a custom framework on the iPhone even though the framework works fine on Mac.
I would go with method 2.
You could develop your application in JavaScript, CSS, and HTML. You would use the WebView and UIWebView objects on the Mac and the iPhone respectively. You can do pretty much anything you want in the WebView objects, even make calls down to Objective-C.
The QuickConnectiPhone installer, found here https://sourceforge.net/projects/quickconnect/, installs QuickConnectMac and QuickConnectiPhone templates into Xcode.
This way you can quickly create an application in one environment and then migrate the view to the other. In fact the QuickConnect framework is highly modular.
If you don't want to develop in JavaScript the same modular framework is found on the Objective-C side of the templates installed.
It should make it much easier for you to do what you are attempting.