xctool

Mattt Thompson撰写、 Chester Liu翻译、 发布于

控制了构建系统,你就控制了语言,生态系统和整个社区的命运。

Objective-C 这门语言在很短的时间内经历了巨大的变化。在短短几年里,这个乏味的 NeXT 遗迹已经具有了堪称统治地位的影响力。在开源社区对于 Objective-C 丰富的贡献当中,很大的一部分围绕着工具的自主化。

一个典型的例子是 CocoaPods,它展示了技术和社区结合所能创造的影响力。从项目开始到现在的两年时间里,超过 2700 个社区贡献的库和框架被提交上来,可以通过简单的一行 pod install 命令整合到你的项目中。

依赖管理只是 iOS 和 OS X 开发当中被社区所影响的一个方面。其他的例子还有自动化 Provisioning 和发布bug 提交,以及文档

这周我们关注的重点,是一个重新定义了实际的构建过程的工具,是新时代的工具化和集成系统的基石:xctool


xctool 是一个由 Fred Potter 发起的开源项目,来源于他在 Facebook 里有关自动化构建系统的工作。它可以直接替代 xcodebuild,也就是 Xcode.app 自己所依赖的底层工具。

当你在 Xcode 中点击 “Build & Run” 的时候,所有的项目,构建 target 和 scheme 设置都会传递给 xcodebuild,它会调用有关的构建命令然后在设备或者模拟器上创建并启动一个 .ipa 可执行文件。

别误会我的意思,这种工作方式,相对于 Xcode 把它私有的构建系统封装起来让外部应用不能访问到,对开发者来说是一种 福分 。只是曾经试图通过 Terminal.app 和 xcodebuild 交互的人也都认同一点...它的体验并不顺畅。

与其数落这个老旧的工具的诸多缺陷,我们把目光转向这篇文章的英雄人物——XCtool,看看它是如何改变现状的:

美观 & 样式

对于 xctool 你首先会注意到的一点,就是它华丽多彩的输出。

xctool in Action

我们自己作为苹果硬件和软件的消费者,都清楚设计的重要性怎么强调都不为过。在这个方面,xctool 做得非常漂亮。构建过程的每一步都经过清晰的组织,使用 ANSI 彩色字符和一系列 Unicode 装饰字符,使得表现的方式既容易理解又具有视觉吸引力,

同时 xctool 的美丽不仅仅体现了表面:构建过程同样支持以其他工具可读取的格式进行输出:

xctool -reporter plain:output.txt build

输出器

  • pretty: (默认) 一个文字化的输出器,使用 ANSI 颜色和 unicode 符号来进行美化输出。
  • plain: 类似 pretty, 不过没有颜色和 Unicode。
  • phabricator: 把构建/测试的结果输出为 JSON 数组,它可以被 Phabricator 的代码评审工具读取。
  • junit: 把测试结果输出成和 JUnit/xUnit 兼容的 XML 文件。
  • json-stream: 一个由构建/测试事件组成的 JSON 字典流,每行一个(示例输出)。
  • json-compilation-database: 输出构建事件的 JSON Compilation Database ,它可以用于基于 Clang Tooling 的工具,例如 OCLint.

构建系统集成

xctool 相对于 xcodebuild 另一个主要的进步是,xctool 可以和 Xcode.app 一样执行应用测试(xcodebuild 不能区分项目 scheme 中哪些是测试使用的 target,更不用说在模拟器中执行测试了)。

仅仅因为这一个原因,xctool 就深刻地影响了 Objective-C 社区中新兴的持续集成测试的规范。

Travis CI

Travis CI 面向开源项目提供了免费的持续集成服务(同样也提供面向商业软件的收费方案,并且对于 Objective-C 提供了独有的支持。通过配置可以使得它在你每次向 Github (或者其他你喜欢的代码托管网站)进行 git push 的时候都执行测试用例,如果最近的变更破坏了构建过程的话,它还会提醒你。

想要给自己的 Objective-C 项目添加 Travis CI 支持的话,创建一个账号和 webservice hook,然后仓库里新建一个 .travis.yml 文件:

.travis.yml

language: objective-c
before_install:
    - brew update
    - brew install xctool
script: xctool -workspace MyApp.xcworkspace -scheme MyApp test

OCLint

OCLint 是一个静态代码分析工具,可以检查 Objective-C(也支持 C 和 C++)代码中常见的问题,例如空的 if/else/try/catch/finally 语句,未使用的本地变量和参数,大量复杂的没有注释的(NCSS),具有圈复杂度或者 NPath 复杂度的代码,冗余的代码,代码“异味”,以及其他的不好的代码实践。

还记得 xctooljson-compilation-database 输出选项吗?它的输出可以直接 被 OCLint 读取,供它进行魔法一般的静态分析。

在这篇文章书写之际,距离 OCLint 被广泛使用还有很长的一段路要走,我所希望的是,既然已经有了先驱者,一些企业的员工可能会参与进来,基于这个潜力巨大的工具共同创造出更好的体验。


就像面对城市人口的增长问题,基础设施是必不可少的。不管是通过本地的 政府授权 还是 自发的组织,又或者是两者中间的东西,环境都需要进行改变,以适应这种增长。

由于 iOS 的流行,Objective-C 经历了(仍然在进行的)高速发展。和苹果协作(有时候是反对)共同构建能够支持如此多新开发者的基础架构,这个责任落到了社区的头上。在这个方面我们做的是否成功,展示了我们作为专业开发者如何看待和传达自己的角色和责任。

我们是选择做笨拙的初学者,还是选择开始行动,不断精进?

xctool,和许多来自社区的工具一样,给这门语言和社区的未来带来了希望和灵感。让我们继续在这些工具基础上更进一步,创造出让我们自己感到骄傲的开发者体验。