Xcode 中的编译过程以及编译器_xcode编译日志

Xcode的编译过程：

基本步骤大概可以分为4个：

(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 这个术语不能一概而论，具体区别的在这篇博客有讲述。

        如果对编译器本身产生了兴趣，可以一方面可以看看编译原理（程序猿的三大浪漫之一），然后另一方面可以自己了解一个编译器应该怎么写。