I am looking for a simple library ( and/or app - eventually want both ) example ( like a math library or whatever) for iOS which has a makefile for it that I can use as a template to make other makefiles from and learn. Static of course, (and dynamic if iOS supports it so I can have 2+ apps that share common code)
There is lots of incomplete and cryptic info out there but so far I havn't found any nice concise "with these source files" you create a makefile this way to build an iOS "fat" library I can import into other projects.
This would be on a Mac with the ios4 sdk installed.
It is always great to start with something that basically works.
I have created complex makefiles before for unix and windows and for other devices.
thanks.
The first link pictorially represents the process step by step that you've asked then the second link contains a package that allows a programmer to compile a make file based project
click me
click me
If you want to build a static library using a make file and link against it every time you build your Xcode project, you can add a "run script" build phase in your project before all the others, which runs this make file, and then add the built library to your linking phase. If you want a make file that builds the entire iOS project, I don't think it's posible (you can use the command line to compile the project without Xcode opened though).
Related
I just started programming in Xcode and I'm trying to write an iphone application. I started out with a simple template for Iphone development and took it from there. Now I would like to build a command line tool (for converting data) which reuses some of the classes in my iphone project. I managed to add a new target 'convert', link the appropriate source code to the target, make the target dependent on the main target. Everything builds, so far so good, but it does not generate the right executable, it will build only build/Debug-iphonesimulator/convert which is not runnable from the command line (I'm guessing because it is not linked with the right libraries).
~/Documents/XCode/SQLiteTutorial> ./build/Debug-iphonesimulator/convert
dyld: Symbol not found: _OBJC_CLASS_$_NSCharacterSet
Referenced from: /Users/marc/Documents/XCode/SQLiteTutorial/./build/Debug-iphonesimulator/convert
Expected in: /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
in /Users/marc/Documents/XCode/SQLiteTutorial/./build/Debug-iphonesimulator/convert
Trace/BPT trap
Is this possible with xcode at all? I'm not sure what kind of extra information you would need to answer this question, so let me know what to provide, if anything.
Kind regards,
Marc van Kempen.
What if you simply created a different project entirely and then dragged in the relevant classes you wanted to reuse, but instead of copying them, merely used references to them? Just don't select 'copy items into destination's folder' option when you drag the class files into your groups & files pane. That way your CL project always uses the latest version from the main iPhone one.
Having it all in one project would no doubt be cleaner though.
iPhone SDK does not officially support building command-line tools. iPhone does not run command-line tools; at least, not without jailbreaking.
I have found an existing open source library that I would like to include in my iPhone project (the unrar source code found here: http://www.rarlab.com/rar_add.htm ).
I have compiled this source as a linked library on my Mac with "make lib" which creates the libunrar.so file just fine.
These are the makefile settings for that target:
lib: WHAT=RARDLL
lib: $(OBJECTS) $(LIB_OBJ)
#rm -f libunrar.so
$(LINK) -shared -o libunrar.so $(LDFLAGS) $(OBJECTS) $(LIB_OBJ)
Obviously I can't use this on iPhone but I imagine I should be able to compile with different options to make a static library that I can use.
Do I:
Compile it on the Mac with different make options then drag the resulting library (some kind of .a ?) into my xcode project?
or
Drag all of the source code into my xcode project and create special targets of some kind to create it?
or
Something else entirely different?
I've been working on solving my unrar problem for a couple of weeks now and I believe using this library will give me the best results but I just don't know the final steps to make use of it.
Thanks for all advice.
I think that you'll probably want to do the easiest thing first, create an empty iPhone project and bring all of the code into it, just to see if it will compile.
If so, you may want to use the empty project to aid in the development of an Objective-C wrapper, once that is complete you can bring the code into your existing project for integration and testing.
If it looks like this is code that you would like to use with other projects, or you are feeling giving and would like to provide an iPhone port of the code, go ahead and pull this together into a library.
Here is a site that documents the process.
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've developed a static library that I'd like to share between XCode projects. I did some reading to learn exactly how to include this library as a binary dependency so that it runs on both the device and the simulator and that lead to a couple of manual steps which I'd now like to automate. Overall I'd like to be able to release new versions of my library and have a simple upgrade process for any project using the older version. Currently that process consists of deleting and/or copying the new binary files over the original location, deleting copying over new header files. The initial install consists of the same two steps along with additional project/target level configuration to set conditional linker flags based on the target SDK. Is there a way this could be automated? I mean I know I could do something like write an Applescript to do the heavy lifting but how? Has anyone ever automated xcode build settings via applescript? How would I call into XCode via Applescript? Are there any other alternatives? Is there a better way to maintain binary level dependencies?
Update
I'm looking to maintain a binary level dependency where project A depends on a static library created by project B. Something similar to a framework that can be included into an XCode iPhone project easily. After building "B" I want something that can practically be dropped into and project including A. While I am becoming aware of all the procedures around leveraging such a dependency I am looking for some solutions to soften up all of the rough edges.
Add a custom build script through Xcode:
select your target under the Targets group on the left
select Add -> New Build Phase -> New Run Script Build Phase
double click on the new Run Script item underneath your target
this allows you to write a shell script, accessing most of the Xcode environment variables related to the current build, e.g. $BUILT_PRODUCTS_DIR
if you check the "Show environment variables in build log" and view the detailed build output you can see all the variables available.
Have a Google search and you'll find lots of examples, e.g. section 20.3 here etc.
If you are using Subversion I believe you can use SVN externals to specify which particular version of your library to use.
You just have to drag & drop your library project in your project. xCode will dot the rest...
Regards,
Thierry
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.