前提开启use_frameworks！
#该参数已经在1.5.0设置为不需要再podfile中声明
第一种 静态库互相依赖，这种情况非常常见，制作静态库的时候只需要有被依赖的静态库头文件在就能编译出来。但是这就意味者你要收到告诉使用者你的依赖关系
第二种动态库依赖动态库，两个动态库是相互隔离的具有隔离性，但是制作的静态库的时候需要被依赖动态库参与链接，但是具体的符号决议交给dyld来做。
第三种，静态库依赖动态库，也很常见，静态库制作的时候也需要动态库参与链接，但是符号的决议交给dyld来做。
第四种，动态库依赖静态库，这种情况就有点特殊了。首先我们设想动态库编译的时候需要静态库参与编译，但是静态库交由dyld来做符号决议，but 这和我们前面说的就矛盾了啊。静态库本质是一堆.o的打包体，首先并不是二进制可执行文件，再者你无法保证主程序把静态库参与链接共同生成二进制可执行文件。
1.3.0
- vendored_libraries 可添加第三方静态库（.a）
- 但是pod均会被指向 动态framework的结果
- 此时静态库是否可以link成功取决于生成动态库过程静态库是否能够被完整load成功吸附
1.4.0
- 增加静态库支持，打开后pod可被指向静态库结果，与link过程无关
s.static_framework = true
- 此时dependency 静态库有问题，为pod不支持的方式
1.5.0
- 此时支持module方式，所以在pod源文件中对于系统库的引用有要求，有两种方式解决
- 开启系统 ：allow non-modular included in framework modules -》 YES
- 调整源文件实现，支持module
