三、carthage编译
因为Carthage工程是Swift编写的，并且是使用Carthage进行的依赖管理。 我们可以从github上Clone相关的代码，然后执行carthage update进行依赖库的加载，如下所示：
加载完毕后，我们就可以正常编译运行了，下篇博客会介绍Chathage的相关源代码的设计结构。
四、Carthage VS CocoaPods
两者各有各的好处，也各有各的缺点，下方是Carthage的README中给出的与CocoaPods的不同之处。
下边是根据上面的英文自己翻译了一下：
CocoaPods是一个长期在Cocoa项目中使用的包管理工具，但为什么还要去创建一个Carthage呢？
首先，CocoaPods默认是会为你的工程自动创建和更新一个Xcode工作空间，并且还会创建和更新所有的依赖（备注：安装pod后会创建一个xxxxxx.xcworkspec的文件，通过该文件可以打开Xcode工作空间，该工作空间除了你自己的project外，在Pods中还会引入其依赖的三方库的源代码）。而Carthage与其不同，其会使用xcodebuild工具将依赖的库编译成二进制的framework, 但是整合这个framework的责任就落到了用户的身上。浸入式的CocoaPods使用起来会更为容易一些，而非浸入式的Carthage使用起来则更为灵活。
下方是CocoaPods的README中列举的目标之一：
通过创建更集中的生态系统，提高第三方开源库的可发现性和参与度。
相比之下，Chathages是分散式依赖管理器。没有集中的依赖清单（就是内个CocoaPods中的SPEC仓库），这减少了维护工作，避免了任何中心故障点。然而，开源项目的发现变得更加困难，用户必须在github等开源网站上进行自行搜索。
CocoaPods的工程目录中必须有一个叫做podspec的这么一个文件，其中包含有关项目的元数据并指定了工程的的编译方式。Carthage使用了xcodebuild工具来构建依赖关系，而不是将这些依赖集成到单个工作区域中。它没有类似podspec这样的文件，但你的依赖项必须包括它们自己的XCODE项目，在这些项目中提供了依赖库的编译规则。
最终，我们创建了Carthage，因为我们想要最简单的工具——该依赖性管理器，它在不承担Xcode所做的工作的的情况下完成自己依赖管理的工作，并且不为框架作者创建额外的工作。虽然CocoaPods提供了许多令人惊喜的特性，但Carthage将永远不会有，因为这样会以增加工具的复杂度为代价。
五、CocoaPods结合Cathage进行二进制化。
不过我们可以将两者结合起来，比如一个浩大的工程中引入了成百上千个依赖库，如果都以源码的形式加载的话，编译成本难免会比较大。我们可以在CocoaPods中加载Carthage生成的framework, 来达到CocoaPods的二进制化的目的。
我们可以在CocoaPods的Podfile中添加相关的定义，具体如下所示。在else的语句块中就是加载Carthage编译的framework。
添加完相关Pod配置后，我们可以pod install看医生相关的库是否顺利的加载进来了。
下方就是我们pod install后相关的内容，可以看到依赖的仓库通过了framework的形式被引入到了我们的CocoaPods中，并且可以正常使用。
我们可以通过指定SOURCE条件来切换源码加载。