does new versions of xcode support cross-project references for adding static library for linking?

Question

I have seen some static library projects in iOS.I see two different types of linking static library.

a)adding .a static library to new xcode project and its header files only.It means universal static library.

b)adding .a static library to new xcode project and adding the xcode project through which static library has created.this is called as cross project reference?Example : adding cocos2d to xcode 3.2

when I remove the the xcode project through which static library has created from the 2nd project, it gives error.I tried first approach for 2nd one.But it is not working.

1)Can you please explain why it is differed? Will it be differed by the xcode versions we use? is The second approach for old xcode versions?

2)are Recent xcode versions such as xcode 4.3 supporting cross project refeence?if it supports,which is the better approach? what is the differnce between that two approches?

Answer 1

Let me first explain roughly what are .a files and frameworks. In Cocoa you write your classes in into .m files, more or less on class per file. When you compile your project the compiler processes each of your .m files one by one and generates the binary representation (machine code) of your source code together with some header information like the list and offset of the methods of the object. The result is one .o object file for each .m source code file. Now if you are linking for a static library, all of these object files are packed into an .a archive file for a given platform: i386 for simulator, armv7 and armv7s for device. To use these archives you also need to public header files of the SDK (even if it is possible to extract the same information from the archives). A .framework bundle is simple a set of these .a files for each architecture to be supported, plus the public header files, arguably nicely packed into one single bundle. As the linking is "static", at the time when you link your final executable the .o files will be extracted from the .a files and copied into the binary of your final executable.

Some static library providers do not want to reveal the source code of their libraries to third party developers and thus release only the .a binaries. Example of such libraries are Facebook or Aviary SDKs. When you add the .a file to your project you are effectively adding the binary representation of the compiled objects. As you have access also to the headers, you can still use these binaries, even if you have no access to the source code.

When you are working with an embedded project you have access to the source code of the library. In this case XCode will first compile your embedded project once again generating the .o and then the .a file from the original .m source code files. Then it starts compiling your application which declares its dependency against the .a file of the library that this time is readily available as it was just compiled seconds ago by XCode. So the linking succeeds. On the other hand when you remove the embedded project it will delete not only the source code files but also the resulting .a file so the linking of your final application will fail.

As you can see from the point of view of the final binary there are no differences whether you use a precompiled .a file or an embedded project, the same .o files will end up in your final binary, just in the first case they were compiled by the provider of the library and in the second case by you. The only pro for using the .a file even if you have access to the source code is the somewhat faster compile time. The con is that the debugger will need additional configuration to be able to step into the source code of the library.

Anyway if you want to remove the embedded project you can do it. Compile the library once as a static library and search for the resulting .a files in the target directories. Copy the .a files for each architecture into the project folder of your application and add them to the project together with the public header files and compile your final application.