拿 CocoaPods 来管理用到的第三方开源库可太方便了，0.36 用上了应用内框架，0.38清理了 Targets 的结构、名字也更清楚了，越来越好用了。

把自己的项目也拆成某干 pod 的想法很自然的就冒出来了，这样把 CocoaPods 当基本的工程管理工具使，需要建一个私有的 Pod 仓库，当然解构工程也是必须的。

起初，看完文档我的设想是这样的:

不过，不停的踩坑时不时需要做一些关于spec写法之类的试验了，而让这些试验出现在 git 历史里显然是不好的。解决这个需要一个更安全也更复杂一点的环境，于是仓库结构进化成：

是呀，已经复杂到需要画个图随时给自己瞅一眼才能保持清醒了呢！

==更新： 啊！原来 resource 方式是可以工作的！

有一个工程模块里用到了 CoreData 并向主应用工程提供 model (.xcdatamodeld)，然后这个东东在 pod install 之后居然没出现。若干试验之后，我认为将 .xcdatamodel 本身加到 source files 里才是“自然”的，这样 pod install 之后文件倒是出现了，但是生成的 Pods project 并没有引用它，更不用说加到 target 的编译文件清单里了。

怎么折腾都不行，看来不瞅一眼源码是不行了。CocoaPods 是拿 Ruby 写的，而 Ruby 一直没学过(主要是 n 年前在上海交大某个 Ruby 讲座上被鼓吹者恶心到了，File.open() 这种设计真的好吗？)，这也是一直折腾没去看源码的原因，是得现学一下了。

好在 Ruby 语言还是比较简单的，啃了半天的教程 (http://ruby-doc.com/docs/ProgrammingRuby/) 然后时不时再查一下快速参考(http://www.zenspider.com/Languages/Ruby/QuickRef.html) 也就可以上手了。教程写得挺好，就是略啰嗦，整理成了一个 Freemind 笔记，估计只有我自己看得明白了:

–才发现有个更合适的教程，(http://edwinmeyer.com/Release_Integrated_RHG_09_10_2008/)，当时咋没找到呢，看这个可以省不少时间的。

CocoaPods 的代码初看有点晕，主要是找不到程序的入口点，后来把依赖的 CLAide 子项目看了才搞清楚，后面就比较顺利了。没用多就发现，file_accessor 使用了Dir glob 来扫描 clean 过后留下来的文件，而这个方法不知道某些目录是 bundle 应该当文件使，考虑到代码没有通读，恐怕直接调整 file_accessor 的这个部分会有副作用，所以做了个补丁加在专门处理源文件引用的地方。

这个快速略 dirty 的补丁 PR 给 CocoaPods 了，如果你正好有同样的需要，可以先用我的这个 fork (https://github.com/pinxue/CocoaPods)。Clone 之后要手工安装：

gem build ./cocopods.gemspec
sudo gem install --local ./cocoapods-0.39.0.beta.4.gem

唔，CocoaPods 居然有 1645 spec requirements (unit tests) + 1650 integration test requirements，吓着我了。