记一次蛋疼的debug经历（cycle inside）

甲方公司的大部分业务都是做成私有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小时，果然魔鬼都在细节里。以后还是要认真查看报错信息，不要单纯依赖搜索，更加不要指望清缓存