| title | author | translator | category | retired | excerpt | status | ||
|---|---|---|---|---|---|---|---|---|
xctool |
Mattt |
Chester Liu |
Open Source |
true |
控制了构建系统，你就控制了语言，生态系统和整个社区的命运。 |
|
控制了构建系统，你就控制了语言，生态系统和整个社区的命运。
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 做得非常漂亮。构建过程的每一步都经过清晰的组织，使用 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 面向开源项目提供了免费的持续集成服务（同样也提供面向商业软件的收费方案，并且对于 Objective-C 提供了独有的支持。通过配置可以使得它在你每次向 Github （或者其他你喜欢的代码托管网站）进行 git push 的时候都执行测试用例，如果最近的变更破坏了构建过程的话，它还会提醒你。
想要给自己的 Objective-C 项目添加 Travis CI 支持的话，创建一个账号和 webservice hook，然后仓库里新建一个 .travis.yml 文件：
language: objective-c
before_install:
- brew update
- brew install xctool
script: xctool -workspace MyApp.xcworkspace -scheme MyApp test
OCLint 是一个静态代码分析工具，可以检查 Objective-C（也支持 C 和 C++）代码中常见的问题，例如空的 if/else/try/catch/finally 语句，未使用的本地变量和参数，大量复杂的没有注释的(NCSS)，具有圈复杂度或者 NPath 复杂度的代码，冗余的代码，代码“异味”，以及其他的不好的代码实践。
还记得 xctool 的 json-compilation-database 输出选项吗？它的输出可以直接 被 OCLint 读取，供它进行魔法一般的静态分析。
在这篇文章书写之际，距离 OCLint 被广泛使用还有很长的一段路要走，我所希望的是，既然已经有了先驱者，一些企业的员工可能会参与进来，基于这个潜力巨大的工具共同创造出更好的体验。
就像面对城市人口的增长问题，基础设施是必不可少的。不管是通过本地的 政府授权 还是 自发的组织，又或者是两者中间的东西，环境都需要进行改变，以适应这种增长。
由于 iOS 的流行，Objective-C 经历了（仍然在进行的）高速发展。和苹果协作（有时候是反对）共同构建能够支持如此多新开发者的基础架构，这个责任落到了社区的头上。在这个方面我们做的是否成功，展示了我们作为专业开发者如何看待和传达自己的角色和责任。
我们是选择做笨拙的初学者，还是选择开始行动，不断精进？
xctool，和许多来自社区的工具一样，给这门语言和社区的未来带来了希望和灵感。让我们继续在这些工具基础上更进一步，创造出让我们自己感到骄傲的开发者体验。