聊聊Xcode 中的编译过程以及编译器

编译过程

基本的编译过程分为四个步骤：

1. 预处理（Pre-process）：把宏替换，删除注释，展开头文件，产生 .i 文件。

2. 编译（Compliling）：把以前的 .i 文件转换成汇编语言，产生 .s文件。

3. 汇编（Asembly）：把汇编语言文件转换为机器码文件，产生 .o 文件。

4. 连接（Link）：对.o文件中的对于其余的库的引用的地方进行引用，生成最后的可执行文件（同时也包括多个 .o 文件进行 link）。

而后经过解析 xcode 编译 log，能够发现 xcode 是根据 target 分开进行编译的。每一个 target 的具体的编译过程也能够经过展开 log 日志得到。基本的格式就是首先简明一句说明要干什么，而后缩进的几行说明具体的操做。好比：

(1) ProcessPCH /.../Pods-SSZipArchive-prefix.pch.pch Pods-SSZipArchive-prefix.pch normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    (2) cd /.../Dev/objcio/Pods
        setenv LANG en_US.US-ASCII
        setenv PATH "..."
    (3) /.../Xcode.app/.../clang 
            (4) -x objective-c-header 
            (5) -arch armv7 
            ... configuration and warning flags ...
            (6) -DDEBUG=1 -DCOCOAPODS=1 
            ... include paths and more ...
            (7) -c 
            (8) /.../Pods-SSZipArchive-prefix.pch 
            (9) -o /.../Pods-SSZipArchive-prefix.pch.pch

就是在处理 pch 头文件，首先切换到 pch 的目录下，而后设置环境变量，而后启动 clang 并进行一系列的配置。在这以后通常就会产生具体的 .o文件做为产出（通常是有多个，针对不一样的平台架构分别有一个，不过通常紧接着会把这些聚合成一个通用的 library。）。同时注意，不一样的 target 也是有编译顺序的，具体的要看 target 之间的依赖关系。

在 xcode 编译的过程当中，大部分的命令均可以自解释，不过仍有个别的命令直接看是看不出来干吗的，这里解释一下：
ld :用于产生可执行文件。
libtool：产生 lib 的工具。
（这部分将会在以后的文章的编译具体过程进行讲解）

接下来就是编译过程的控制，在 xcode 中能够经过 Build phases,Build settings以及 Build rules来进行控制。

Build phases主要是用来控制从源文件到可执行文件的整个过程的，因此应该说是面向源文件的，包括编译哪些文件，以及在编译过程当中执行一些自定义的脚本什么的。
Build rules 主要是用来控制如何编译某种类型的源文件的，假如说相对某种类型的原文件进行特定的编译，那么就应该在这里进行编辑了。同时这里也会大量的运用一些 xcode 中的环境变量，完整的官方文档在这里：Build Settings Reference
Build settings则是对编译工做的细节进行设定，在这个窗口里能够看见大量的设置选项，从编译到打包再到代码签名都有，这里要注意 settings 的 section 分类，同时通常经过右侧的 inspector 就能够很好的理解选项的意义了。

最后，要说一下咱们的工程文件.pbxproj,以上的全部的这些选项都保存在这个文件中。固然也包括 target 的信息，项目全部文件的信息，这个文件是一个文本文件，能够用文本编辑器打开。里头的内容基本是可读性比较强的。基本的思路很面向对象，每一个东西都有属性，若是属性是另外一个对象，值就是那个对象的一个『引用』，就是一串数字（惟一的）做为表示。每一个对象都有这样的引用。

编译器

首先，编译器是作什么的？编译器是用来把源代码文件转换为更为低级的语言的（同时还有语句的静态分析），而 xcode 使用的clang 编译器的做用就是把源代码转换为更为低级的 LLVM IR(Intermedia Representation)，这个 LLVM IR 是操做系统无关的，而后 LLVM 经过这个中间语言来进行下一步的二进制文件的产出。得益于 LLVM 的三层架构，LLVM 能够有多个输入和输出（LLVM 的第一层架构是用于处理输入的，第二层用于优化 IR ，第三层用于输出）这里遇到了一个问题，不了解到底 clang 和 LLVM 之间的关系是什么，估计得明白编译器是怎么作的才能明白。

一般一个编译器能够编译多种语言，生成多个平台的代码，因此会划分前端和后端。有时候还有中端的说法。

前端是语言相关的，输出为抽象语法树；
后端是机器相关的，输出为机器代码。有些优化是机器无关的，这一部分可能被单列出来称为中端。

以gcc为例，前端生成的中间语言为GENERIC，以后转化为gimple作机器无关的优化，最后转化为RTL作机器相关优化并生成机器代码。
这三个部分就能够分别称为前端、中端、后端。不过gimple阶段是gcc 4以后才有的，gcc 3.x的版本优化全在RTL上。
并且实际实现的时候可能机器相关的优化也在gimple阶段实现（反过来RTL也有机器无关优化），划分不是那么明确。

也就是说前段完成语法分析句法分析等相关的工做，并不会针对机器平台作想对应的优化。后端才是真正蟾蜍机器码的部分。clang 只是一个编译器的前前端部分。而 LLVM 这个术语不能一律而论，具体区别的在这篇博客有讲述。

若是对编译器自己产生了兴趣，能够一方面能够看看编译原理（程序猿的三大浪漫之一），而后另外一方面能够本身了解一个编译器应该怎么写。
这里有个知乎专栏
同时还有斯坦福大学的公开课供学习参考。