cat jjgod >> log

我以前总说 autotools sucks，以为只用 make 就能解决一切问题。

最近终于开始做一套比较实用的 (或者说 Insdustrial-strength) 的程序，涉及好几个平台和库，于是 make 的局限性就显现出来了，为了在几个不同的平台下都编译使用，不得不在 Makefile 里写大量判断。

于是开始找跨平台的编译工具，其中最有名的两个是 cmake 和 scons，cmake 之所以出名估计是因为 KDE 4 从 autotools 转向用 cmake 来编译。而 scons 则是 lighttpd 原来用的编译工具，它现在也转向 Python 了。cmake 和 python 大概代表了新一代跨平台编译工具的两种方向。第一种 (cmake) 是延续并改良传统 automake, autoconf 工具链，将之合为一体，但最终仍然生成 Makefile, Visual Studio 的 .sln，Xcode 的 .xcodebuild 文件，依赖现有编译工具 (make, nmake, vcbuild, xcodebuild) 来编译；第二种则是完全消除现有编译工具的调用，直接调用编译器，scons 就属于这一类 (scons 还有一个特点是完全不用专门的语言，控制编译的脚本就是 Python)。

从人气上来说，反倒是走改良路线的 cmake 比 scons 好一些，有几个原因：scons 基于 Python，可能有些代码不是很照顾速度，于是类似 KDE 这样的大项目编译起来会很慢；scons 开发比较慢，最近一直只是 bugfix。不过相对 cmake，scons 的优点是文档非常细致可读，而 cmake 的文档则非常少，可以在网上找到的只有几篇介绍性的文章和参考手册，不像 scons 有一本 User Guide。

与之相关的工具还有 Jam (包括它的变体 FTJam, Boost.Build), Waf, Bakefile 等。其中比较新的 Waf 是一个 scons 的改进，在它的提供的 benchmark 中，显示通过缓存方式可以大大改进编译的速度。不过因为这个项目还很新，目前没有什么软件用它作为编译系统。

Bakefile 走的则是 cmake 的路子，从名称上也可以看出，它最终也是通过生成 Makefile 一类的文件来完成编译的。不过不同的地方在于 cmake 用的语法很像 autotools 用的 m4 的传统语法，而 bakefile 则完全用 XML 来定义编译规则了，这一点倒很像 ant。Bakefile 倒是有不少著名的项目使用，比如 wxWidgets, WebKit, VCF, libxml。

我自己挑来选去，最终决定用 cmake，不过选择的过程写下来，希望能对遇上同样问题的朋友有用。

Rands In Repose 上有一篇 TextMate 主创者 Allan Odgaard 的 Interview，提及了一个敏感的话题：TextMate 会开放源代码吗？Allan 的答复是，他最终还是决定开公司，不开源，他的观点是：

1. TextMate 已经是部分开放源代码的 (Bundle 部分)。
2. 他本人喜欢设定一个确定的目标，得到一个确定的结果的方式，如果采用开源软件的开发方式，他无法要求参与的开发者都按照他的意愿工作，所以他宁可开个公司。
3. 他还是担心开源了就赚不到钱。

虽然让人有点失望，但这也是正常的思路，你不可能指望所有的编辑器作者都像 Bram Moolenaar 那样去救助乌干达的可怜儿童，所以 InType 早在没有出 Alpha 之前就说他们是肯定要卖钱的，而虽然早有人说靠 TextMate 40 欧元每份的价格，Allan 早已赚得盆满钵满，但还是舍不得开源。

作为一个购买了 TextMate 的用户，我关心的是什么呢？

1. 我提的问题是不是有人回复
2. 如果没有人回复，我能不能自己去改进它

我最热爱开源软件的地方正是第二点，我可以完完全全地按照自己的意愿去改进它，如果我的改进能被主干接受当然更好，如果不接受也没关系。就拿 TextMate 为例，我被它处理正则表达式的问题困扰，但因为 Allan 去旅行了两个半月，没有人能回答我的问题，结果我只能坐着等 (事实上，Allan 今天刚刚从旅行回来，我甚至根本不知道我两个月前提的问题他会不会看，一想到这一点我就抓狂)，如果困扰我的是 Smultron, Vim, 这样的问题早就解决了。

如果开公司，是可以保证比较稳定的客户服务，但无形中失去了很多程序员的业余贡献，比如我的主业是 Linux 内核驱动的开发，如果 TextMate 开源，我倒是乐于贡献，但要让我去做一辈子编辑器，恐怕就不会原意了。

当然，开源也有很多弊端，软件项目管理本来就是一件很难两全的事情。