Xcode 工程设置及含义

关于Objective-C，Modules和Autolinking

OC自从Apple接手后，一直在不断改进。随着移动开发带来的OC开发者井喷式增加，客观上也要求Apple需要提供各种良好特性来支持这样一个庞大的开发者社区。iOS4时代的GCD，iOS5时代的ARC，iOS6时代的各种简化，每年我们都能看到OC在成为一种先进语言上的努力。基于SmallTalk和runtime，本身是C的超集，如此“根正苗红”的一门语言，在今年也迎来的新的变化。

今年OC的最大变化就是加入了Modules和Autolinking。

什么是Modules呢

在了解Modules之前我们需要先了解一下OC的import机制。

import <FrameworkFoo/HeaderBar.h>

我相信每个开发者都写过这样的代码，用来引用其他的头文件。熟悉C或者C++的童鞋可能会知道，在C和C++里是没有#import的，只有#include（虽然GCC现在为C和C++做了特殊处理使得imoprt可以被编译），用来包含头文件。#include做的事情其实就是简单的复制粘贴，将目标.h文件中的内容一字不落地拷贝到当前文件中，并替换掉这句include，而#import实质上做的事情和#include是一样的，只不过OC为了避免重复引用可能带来的编译错误（这种情况在引用关系复杂的时候很可能发生，比如B和C都引用了A，D又同时引用了B和C，这样A中定义的东西就在D中被定义了两次，重复了），而加入了#import，从而保证每个头文件只会被引用一次。

如果想深究，import的实现是通过#ifndef一个标志进行判断，然后在引入后#define这个标志，来避免重复引用的。

实质上import也还是拷贝粘贴，这样就带来一个问题：当引用关系很复杂，或者一个头文件被非常多的实现文件引用时，编译时引用所占的代码量就会大幅上升（因为被引用的头文件在各个地方都被copy了一遍）。为了解决这个问题，C系语言引入了预编译头文件（PreCompiled Header），将公用的头文件放入预编译头文件中预先进行编译，然后在真正编译工程时再将预先编译好的产物加入到所有待编译的Source中去，来加快编译速度。比如iOS开发中Supporting Files组内的.pch文件就是一个预编译头文件，默认情况下，它引用了UIKit和Foundation两个头文件–这是在iOS开发中基本每个实现文件都会用到的东西。

于是理论上说，想要提高编译速度，可以把所有头文件引用都放到pch中。但是这样面临的问题是在工程中随处可用本来不应该能访问的东西，而编译器也无法准确给出错误或者警告，无形中增加了出错的可能性。

于是Modules诞生了。Modules相当于将框架进行了封装，然后加入在实际编译之时加入了一个用来存放已编译添加过的Modules列表。如果在编译的文件中引用到某个Modules的话，将首先在这个列表内查找，找到的话说明已经被加载过则直接使用已有的，如果没有找到，则把引用的头文件编译后加入到这个表中。这样被引用到的Modules只会被编译一次，但是在开发时又不会被意外使用到，从而同时解决了编译时间和引用泛滥两方面的问题。

稍微追根问底，Modules是什么？其实无非是对框架进行了如下封装，拿UIKit为例：

framework module UIKit {
umbrella header "UIKit.h"
module * {export *}
link framework "UIKit"
}

这个Module定义了首要头文件（UIKit.h），需要导出的子modules（所有），以及需要link的框架名称（UIKit）。需要指出的是，现在Module还不支持第三方的框架，所以只有SDK内置的框架能够从这个特性中受益。另外，在C++的源代码中，Modules也是被禁用的。

好了，说了那么多，这玩意儿怎么用呢？

关于普通开发者使用的这个新特性的方法，Apple在LLVM5.0（也就是Xcode5带的最新的编译器前端中）引入了一个新的编译符号@import，使用@符号将告诉编译器去使用Modules的引用形式，从而获取好处，比如想引用MessageUI，可以写成

@import MessageUI;

在使用上，这将等价于以前的

#import <MessageUI/MessageUI.h>

，但是将使用Modules的特性。如果只想使用某个特性的.h文件，比如

#import <MessageUI/MFMailComposeViewController.h>

对应写作

@import MessageUI.MFMailComposeViewController;

当然，如果对于以前的工程，想要使用新的Modules特性，如果要把所有头文件都这样一个一个改成@import的话，会是很大的一个工作量。Apple自然也考虑到了这一点，于是对于原来的代码，只要使用的是iOS7或者MacOS10.9的SDK，在Build Settings中将”Enable Modules(C and Objective-C)”打开，然后保持原来的#import写法就行了。是的，不需要任何代码上的改变，编译器会在编译的时候自动地把可能的地方换成Modules的写法去编译的。

Autolinking是Modules的附赠小惊喜，因为在module定义的时候指定来link framework，所以在编译module时LLVM会将所涉及到的框架自动帮你写到link里去，不再需要到编译设置里去添加了。

常见工程设置及含义

Prefix Header

指定 PCH 文件位置

Precompile Prefix Header

是否预编译 PCH 文件

Search Paths

指定非系统文件的位置，如引入的c语言的头文件位置，第三方framework等

引入第三方 framework 相关设置

framework search path

指定第三方 framework 所在位置

copy files

将第三方 framework 拷贝到自己程序，特别是资源文件

Runpath Search Paths

指定可执行文件的位置。一般可以设置为 “@executable_path/something”。详情

工程设置常用变量

@executable_path

这个变量表示可执行程序所在的目录. 比如 /path/QQ.app/Contents/MacOS/

@loader_path

这个变量表示每一个被加载的 binary (包括App, dylib, framework,plugin等) 所在的目录.

在一个程序中, 对于每一个模块, @loader_path 会解析成不用的路径, 而 @executable_path 总是被解析为同一个路径(可执行程序所在目录). 比如一个会被多个程序调用的 plugin, 位于 /path/Flash Player.plugin/Contents/MacOS/Flash Player, 依赖 /path/Flash Player.plugin/Contents/Frameworks/XPSSO.dylib. 那么 XPSSO.dylib 的 INSTALL_PATH 可以设置为 @loader_path/../Frameworks, 这样设置的话, 不论 Flash Player.plugin 目录放到什么位置, XPSSO.dylib 都能正确的被加载.

@rpath

和前面两个不同, 它只是一个保存着一个或多个路径的变量. 比如 XPSSO.dylib 被两个 .app 使用, 且被包含的路径不同。比如：

softA.app/Contents/MacOS/dylib/XPSSO.dylib

softB.app/Contents/MacOS/Frameworks/XPSSO.dylib

将 XPSSO.dylib 的 INSTALL_PATH 设置成 @loader_path/../dylib 或 @loader_path/../Frameworks 都只能满足其中一个 .app 的需求. 要解决这个问题, 就可以用 @rpath. 将 XPSSO.dylib 的 INSTALL_PATH 设置成 @rpath, 然后在编译 softA.app, softB.app 时分别指定 @rpath 为 @loader_path/../dylib, @loader_path/../Frameworks, 问题得到了解决. @rpath 的另一个优点是可以设置多个路径. 如果 softA.app 还需要使用另一个 .plugin (假设它的 INSTALL_PATH 也设置成了 @rpath), 位于 @loader_path/../plugin, 把这个路径加到 @rpath 即可.

XPSSO.dylib的Build Settings中设置Installation Directory



在 softA.app或softB.app 中设置 Runpath Search Paths(对应了@rpath)

参考

Build Settings中的变量@rpath,@loader_path,@executable_path