This question will be easy for Xcode pros but for a MonoTouch developer it seems to be impossible to resolve. :-)
I'm using Xcode 4.5 and I want to target iOS 5.1 and above and iOS Simulator 5.1 and above.
I have a a library project here and it is coming with a prebuilt binary named "DemoLib" (no extension and it is 11MB in size). The library is a fat lib for Simulator and iOS 5.1+.
I can use that library without any problem.
However if I try to build the library myself, I end up with a "DemoLib.a" file (notice the extension and the size of 30MB). How can I get the same build result? What is a .a file compared to the file without extension?
I tried to build the project "for running", and "for archiving" in Xcode. Both results in the same 30MB .a file.
I was expecting some dropdown in Xcode where one could select "DEBUG" or "RELEASE" build and the latter one would create the smaller lib.
Of course I could never tell without seeing the framework's project file. Having said that, there is an excellent guide to creating and compiling iOS frameworks here: https://github.com/jverkoey/iOS-Framework
Using the above guide, you should be able to recreate your framework's project from scratch, add the files you have to it, and properly compile it.
Hope this helps! :)
Did it come with a Makefile? Create a new target, set the build settings of the target to what's in the Makefile, then set your project to depend on that new target.
A file with the .a is a static library, which means it depends on nothing external and all the code it needs is compiled inside it. I think no extension generally implies dynamic library, which means it'll depend on some dependencies being present on your system to link against. Maybe that's why the .a is so much bigger. I think Xcode will build static by default because iOS does not allow the use of dynamic libraries.
The dropdown for what to build is in your scheme. Command+shift+< to view your scheme. Within the scheme you can edit which environment each method of building will use.
Related
I just realized the tensorflow has supported ios now. But how to compile the example in contrib/ios_examples directory?
thanks!
josh
We're still finishing off all the documentation, but here's a draft of the README I'll be adding to the ios_examples directory. I'd be interested to hear if this helps, and if you have ideas for improvements.
TensorFlow iOS Examples
This folder contains examples of how to build applications for iOS devices using TensorFlow.
Building the Examples
You'll need Xcode 7.3 or later, with the command-line tools installed.
Follow the instructions at tensorflow/contrib/makefile to compile a static library containing the core TensorFlow code.
Download Inception v1, and extract the label and graph files into the data folders inside both the simple and camera examples.
Load the Xcode project inside the simple subfolder, and press Command-R to build and run it on the simulator or your connected device.
You should see a single-screen app with a "Run Model" button. Tap that, and you should see some debug output appear below indicating that the example Grace Hopper image has been analyzed, with a military uniform recognized.
Once that's been successfully run, make sure you have a real device connected and open up the Xcode project in the camera subfolder. Once you build and run that, you should get a live camera view that you can point at objects to get real-time recognition results.
Troubleshooting
If you're hitting problems, here's a checklist of common things to investigate:
Make sure that you've run the download_dependencies.sh and compile_ios_protobuf.sh scripts before you run compile_ios_tensorflow.
Check that you have version 7.3 of Xcode.
If there are Eigen errors, look inside the build settings of your Xcode project. In the Search Paths section, you'll see an Eigen include directory that changes with each version of the framework. You may need to update this to may the version in your tensorflow/contrib/makefile/downloads folder.
If there's a complaint about no Session's registered, that means that the C++ global constructors that TensorFlow relies on for registration haven't been linked in properly. You'll have to make sure your project uses force_load, as described below.
Creating your Own App
You'll need to update various settings in your app to link against TensorFlow. You can view them in the example projects, but here's a full rundown:
The `compile_ios_tensorflow.sh' script builds a universal static library in tensorflow/contrib/makefile/gen/lib/libtensorflow-core.a. You'll need to add this to your linking build stage, and in Search Paths add tensorflow/contrib/makefile/gen/lib to the Library Search Paths setting.
You'll also need to add libprotobuf.a and libprotobuf-lite.a from tensorflow/contrib/makefile/gen/protobuf_ios/lib to your Build Stages and Library Search Paths.
The Header Search paths needs to contain the root folder of tensorflow, tensorflow/contrib/makefile/downloads/protobuf/src, tensorflow/contrib/makefile/downloads, tensorflow/contrib/makefile/downloads/eigen-eigen-, and tensorflow/contrib/makefile/gen/proto.
In the Linking section, you need to add -force_load followed by the path to the TensorFlow static library in the Other Linker Flags section. This ensures that the global C++ objects that are used to register important classes inside the library are not stripped out. To the linker, they can appear unused because no other code references the variables, but in fact their constructors have the important side effect of registering the class.
The library doesn't currently support bitcode, so you'll need to disable that in your project settings.
I'm creating a modular open-source library. Let's say the project has 15 .m files in it.
Should I (1) release it like the Venmo iOS SDK (Cocoa Touch Static Library) or (2) release it like JSONKit (just the source code)?
Releasing as source code means you, and your developers, don't have problems when a new architecture comes out. A static library built as armv6 wouldn't work with the latest Xcode today.
One caveat with source code releases, since you don't know what build settings the project it's added to will have, you'll need to do extra work to make sure it builds without warnings as best you can, even for pedantic warnings.
I prefer frameworks over static libs. Its easier to ship resources in the framework bundle if you eventually need to and there no cost to dynamic linking. If its pure C and the libraries dependencies are guaranteed to be there then it might be ok. But in general I try to avoid static linking unless I know the target OS has the exact dependencies for that binary at deployment time.
Its much easier to load a dynamic library with the endpoints you need at runtime (which were compiled for that exact platform but have the same external interface) than it is to fail with a static lib that was compiled directly to external dependencies which dont exist on the target platform.
Maybe Im crazy but this is what Ive always done in C, C++ or obj C. Just my opinion.
http://en.wikipedia.org/wiki/Static_library
I have had some issues with the AWS IOS SDK framekit, since it was not built to work with OSX apps. I found a modified version of the SDK that Brad Larson created.
The directory structure looks something like:
AWSiOSSDK.framework/
src/
--Amazon.Runtime/
--Amazon.S3/
..
--AWSCocoa/
----AWSCocoa_Prefix.pch
----AWSCocoa.xcodeproj
----etc
--include/
So if I go into the xcode project, and build AWSCocoa it compiles. But when I look at the timestamp on the AWSiOSSDK.framework, it hasn't changed. So I don't know what compiling this AWSCocoa gets me, or where I can find the files it creates. So assuming that building AWSCocoa.xcodeproj is supposed to build a new version of the framework compatible with OSX development, where do I find and link what I've built?
The AWSiOSSDK.framework bundle is a precompiled framework, probably left over from my earlier experiments in making a Mac version of this (since you can't use frameworks like this with iOS, only static libraries). Ignore that.
If you are using Xcode 4, your built framework will be created somewhere in your ~/Library/Developer/Xcode/DerivedData/ directory. To find where it lies, go to your project navigator in Xcode 4, expand the Products group, right click on AWSCocoa.framework, and select Show in Finder. This is no different from any other third-party framework you would compile.
Nominally, you'll want to add this framework as a target dependency in your application so that it is built alongside that. You'll also have to make sure that the framework is copied into the appropriate location within your application bundle so that it can be used by your application at runtime.
If you create a static library for iOS do you have to distribute the header file(s) with it or is there another way to get it to work?
Currently I have a single my_lib.a file for both device and simulator but when I drag it into another test app to use it, it says it can't find the header and that all the places I'm using it in the code are undeclared. So I figure I'm either doing something wrong, or I have to also send the appropriate header files with it.
Background to my process:
I've seen two guides for creating a static library for both device and simulator. One on this site: Build fat static library (device + simulator) using Xcode and SDK 4+
and one here: http://mark.aufflick.com/blog/2010/11/19/making-a-fat-static-library-for-ios-device-and-simulator
I used the second site to just try it out. I'm also a bit curious if I did it correctly. I just went into the Release-iphone(os|simulator) folders and found the .a in the ios one and the .o in the simulator one.
The short answer is yes, you have to package header files with your static library. You have to package header files with any library in fact, dynamic or static. The library itself contains the compiled code, but you still have to tell the compiler about the identifiers in the library so when it's compiling your code it knows that they exist.
If you care, you can package your static library into a static framework with a little care. You simply create the same directory structure that a dynamic framework has, with your .a file in place of the .dylib (or .so) file. Frameworks contain a directory for headers, so you can distribute the binary and headers as a single package, and you can easily import headers from a framework without messing with the Additional Header Search Paths build setting.
Just in case it's useful - I followed Ray Wenderlich's instructions from here and was able to produce a framework for iOS that supported several architectures at once (including the simulator). The instructions are a bit too long to just copy-paste here.
I have a more general question on working with libraries on with Xcode when building iPhone apps. I've created a framework from a project I've been working on to use some parts of it in other apps. That works pretty good, so far. But I have no idea how to debug into the files included in the included framework.
I hope to get some kind of 'best practice' on that.
Thanks a lot
–f
There have been a lot of discussions of how best to reuse code with static libraries. I've settled on the method described here by Clint Harris (which I think is what Shawn is suggesting as well). Creating a project dependency in this way automatically compiles the library for your project's target (simulator/device, debug/release) so you don't need four different copies of the compiled library sitting around. It also lets you step into the library source when debugging, as you want. Finally, updates to the library are included in any of the linked projects the next time those projects are compiled (so you don't have to recompile and redistribute the library binary to those projects yourself).
Generally, I'll include the Xcode project for the library as an external project dependency of the main application's project. The advantage of project dependencies, is that you can add a build phase that builds a fresh copy of your library along with the main project, and of course it will let you set breakpoints in the library's code.