甲方公司的大部分业务都是做成私有pod的，自己这次接手的也不例外。由所以二次开发，一开始图方便并没有做成pod而是把业务代码悉数放测验工程中。昨天做完之后仿制一下前面的.podspec，修正了部分信息后pod install，pod完成认为没问题了，谁知一运转直接报错：
cycle inside 工程名: building could producce xxx（后面省掉）

这个报错内容仍是挺详细的，但一开始没有多想，直接谷歌搜一下，stackoverflow的确有类似问题。发现许多回答也是只会叫你清缓存清derive data，还有叫你用老的编译系统，移动build phases的次序，甚至还有命令行敞开swift编译环境的。我移动了build phases的次序发现没效果。然后在苹果开发者论坛看到一个教程教你处理库的依靠循环

此时就想着：导致依靠循环的原因难道是头文件的引用出了问题？可是OC的#import也不会重复导入，前面也一向没有报错提示。但也没办法，只能死马当作活马医，先排查了公共头文件，发现的确许多.h都直接引用此文件，所以先挨个解耦。运转，报错依旧。所以继续查看清除一些不必要的引用，仍是没效果。

不得已只能从头查看报错信息，其实一开始就现已丢到翻译网页上，只是内容太长，一向没有细看。这时发现报错提到pod在生成图片资源的时分打出来一个’\\\\.bundle’，和其他组件一比照显着有问题，所以查看.podspec,发现在设置s.resource_bundles的时分，居然是换行的:

s.resource_bundles = {
    'xxx
    ' => ['xxx/Assets/*']
}

并且图片资源里有子文件夹的，也没有加上**/，修正完之后如下

s.resource_bundles = {
    'xxx' => ['xxx/Assets/**/*']
}

修正完从头pod install之后，终于运转成功。真不知道前面第一版是怎么集成进去的。。。

从昨天下午发现问题到现在处理，总耗时估量有6-8小时，果然魔鬼都在细节里。以后仍是要仔细查看报错信息，不要单纯依靠查找，愈加不要指望清缓存