用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管理工程,并解决多静态库依赖的主要内容,如果未能解决你的问题,请参考以下文章