用workspace管理工程,并解决多静态库依赖

Posted 飞羽孟德

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了用workspace管理工程,并解决多静态库依赖相关的知识,希望对你有一定的参考价值。

from:http://www.cnblogs.com/perryxiong/p/3759818.html

 

最近我在项目中遇到一些工程之间的管理问题。

 

模型:

其中 库A 是一个公共的基础静态库, M_A依赖A, N_A依赖A, 而项目工程Test依赖A,M_A,N_A这三个库。

 

用workspace管理项目和依赖的库

Test,A库,M_A库,N_A库分别为4个Project,并被一个workspace进行管理,看截图:

按照常规,我们会在M_A, N_A静态库项目的Build Phases->Link Binary With Libraries中添加A.framework。在Test项目的相同位置添加A.framework,M_A.framework, N_A.framework。

编译一下没有问题。

 

出现Duplicate symbols问题

但是如果A中有某个.m文件仅仅只有类的category。那么默认情况下,是不会被加载的。这个时候我们需要在Build Settings中的Other link flags中添加-ObjC参数。这个时候问题出现了,编译test时会出现duplicate symbols的错误。

这是因为XCode发现存在多份A的object文件,XCode认为这样会出现问题,于是报错。

 

那么如果解决duplicate symbols这个问题呢? 其实很简单,我们在XCode编译M_A.framework以及N_A.framework时不要link A.framework就好了。我们在M_A与N_A的target配置中Build Phases->Link Binary With Libraries删除A.framework。

如下图:

 

Test这个Target是必须要把依赖库加进来的,因为编译成.app必须要link

 

解决工程编译顺序的问题

好了。现在编译一下test工程,发现还是错误,说找不到<A/A.h>。但是再编译两次,第三次就发现编译过了。

原因是在头两次编译中,将A.framework,M_A.framework,N_A.framework编译到build路径下。第三次因为test的库都已经有了,于是就编译通过。这其实涉及到一个编译顺序的问题。XCode先编译test工程了,它发现找不到需要的头文件(这个时候它依赖的库还没有生成好)。

 

XCode总是未卜先知,它可以帮我们解决这个问题。我们在Product->Schemes->Edit Schemes。在左侧表单中选择第一个Build。将Parallelize Build与Find Implicit Dependencies前面的勾去掉。

再将目标文件A.framework,N_A.framework,M_A.framework按依赖顺序插到Test前面,越底层的更靠前,并将后面所有的check box都勾上。如下图:

 

OK确认后,再进行编译,发现是不是没有问题了。

 

Clean Workspace

另外在workspace下,如果想把所有project都clean下,需要点击菜单上的Product后,按住option键,发现Clean命令变成了Clean Build Folder了。点击Clean Build Folder就把workspace下的Build文件夹全部删除掉。

 

 

团队协作

公司往往有一个团队来协作完成一个App,那么怎么把刚才的设置能共别人使用呢?就是别人从代码仓库获取代码后,就有同样的scheme设置。那么我们就要设置下scheme的共享。

在Product->Schemes->Edit Schemes->Manage Schemes...弹出的面板中,将test工程最后面那个checkbox给勾上,lib的勾不勾无所谓。

最后要把这个shemes文件加到仓库中提交, 之前大部分人可能都把它忽略掉得,包括我,因为觉得没用。

 

以上是关于用workspace管理工程,并解决多静态库依赖的主要内容,如果未能解决你的问题,请参考以下文章

IOS-WorkSpace管理两个项目并相互依赖

Xcode编译相关

iOS 使用.xcworkspace文件管理代码和工程依赖(实现项目模块化)

第九课: 工作空间-Work Space介绍

如何在ios framework中引用其他静态库

Xcode创建Workspace,并管理多个子工程