I'm working with an open source library that's made available as a git repository (XML-RPC) and I'd like to use it in an iPad application. As I understand it, iOS applications should use static libraries for their linking.
Since this comes as a dynamic library, how can I convert it to something I can link with my app and use?
Maybe naive answer but why not just add all the relevent files in the repository to your app and just build it?
Put the files in a seperate folder obviously so you can update them to a newer version if you need to etc. Lots of projects I've done have an 'external' folder that just contains codethat I use from 3rd party sources. I've usually got the source so just compile it into my app and don't bother with making it a library.
Or are there tricky conditions that need to be met to compile this code?
I ended up doing this in several steps:
First, I opened the library project in Xcode and created a new target for the static library. I then made a directory in the project folder called "XMLRPC" and moved all the header files to it. I deleted the now-red invalid references to the header files, and re-added them (but kept the box for copying them to the current folder unchecked).
I added this Xcode project to my main project with a relative reference. I opened my main app's target and added the library project as a direct dependency, and checked the "Always search user paths" option on my main app's target settings.
Lastly, I modified the general Xcode preferences to use a shared build directory. I haven't tried it without that since it was something I wanted anyways; it might not be necessary.
My revision control has two folders in it: one's my project, and the other's the library. The library is still under git control within mercurial; I'm hoping this doesn't cause any issues.
Related
So I have a .gitignore created, which I have basic files included in there, but when it comes to a Swift and .xcodeproj project..
Which one of these files are the only ones that I need inside Github?
Actually, you need both .pbxproj and .xcworkspace, however, it depends:
.pbxproj file contains metadata, file references, configuration... which use to execute/build the project.
.xcworkspace contains and manages subprojects. A common scenario is using cocoapods. If you're developing a small project that's don't need to depend on any 3rd parties, you don't have to create xcworkspace.
xcuserdata folder is safe to ignore. It contains some temporary info like user state, files opened, folders opened.
So, I'm working on a project and can't get my XCode 4 workspace to behave. I have the main application as one project in the workspace. I then add the static library project into the workspace. It seems like everything is working okay. I can import files from the other project. It builds, but when I run it, I get this:
dyld: Symbol not found: _OBJC_CLASS_$_iGBC
Referenced from: /var/mobile/Applications/CD00CC83-28E4-4467-96C0-0D1777E21FDA/GBA4iOS.app/GBA4iOS
Expected in: flat namespace
in /var/mobile/Applications/CD00CC83-28E4-4467-96C0-0D1777E21FDA/GBA4iOS.app/GBA4iOS
And crashes. It appears that although Xcode believes the library has been linked, and it builds and runs, the app doesn't actually have the library. But in the derived data folder, it looks like everything that should be there... is there.
I'm going insane with XCode and all it's nuances in settings. Are there sanity checks I can go through to ensure this is working properly? What else can I do?
Edit:
Project settings are valid, and I've already linked the libraries.
Edit 2:
My workspace is setup so the libraries are also in the workspace:
I have removed the lib.a file from the main project and removed it from the Build Phase section, and added it back numerous times. There is no "copy library into destination folder" option when adding it in this way, so I can't do that.
try clean your build, if it don't work, remove the library in build phase and your project folder. When adding the lib to your project, check "copy item to destination if needed", the add that lib in build phase.
I am compiling an app which is a sample app that uses an api. The api contains interface files (java files) and aidl files. Now I have problem in one of the interface file it cannot recognize the one of these aidl files exists in my project.
I have linked the whole api to the build path.
Does anyone has any idea ??
I had the same error, but it was fixed when I cleaned and rebuilded the project.
Projects -> clean project so it can automatically rebuild.
Look closely at your manifest file, check that the package etc are
spelled as you'd expect.
Also dont forget to paste the server's *.aidl and parcelable implementation (java) to your client project. These files has to have the same name and package as they were in the server project.
Here is some similar posts which might help:
ITelephony.aidl not compiling in eclipse
There are basically two possibilities.
(most likely) you need to make the folder that contains aidl files source folder. if you haven't done so, please do it.
You need a clean build.
I have created a cocoa touch static library that contains functionality that I want to include in several apps. This library is linked to libxml and I have the header search path /usr/include/libxml2. The library builds correctly.
I include this library in another xcode project as a reference (by dragging the library xcodeproj file into my app xcode project. I also setup the target to have the library as a direct dependency, setup the header search path to include /usr/include/libxml2, and add libxml2.dylib in the frameworks.
The problem is, when I try to build the project is has a build error:
Libxml/tree.h: No such file or directory.
I initially had this problem trying to build the library and solved it by adding the header search path and framework into the project for libxml2.
Incidentally, i have another app that uses the library but does not use libxml, it builds and runs correctly.
So the problem seems to be using libxml in both the app and a linked library.
Anybody any ideas?
Yours hopefully,
Neil.
You probably need to add the include path /usr/include/libxml2 to both the target and the project.
To add it to the target, right click on the target and select Get Info.
To add it to the project, go to the Project menu > Edit Project Settings.
In both cases, make sure you've selected Configuration: "All Configurations".
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.