- 27
- Sep
OK，我承认以前比较偷懒，看到Autotools这么难，就没有好好面对这个。
刚开始做Ubuntu Tweak时，打包也用autotools，大致地学习了一下，胡乱了改了点，参考了其他一些工程，也把Tweak打包成功了。
后来Tweak转向Python后，我去掉了autotools，改用手动写了个setup.py。近期更改Tweak目录结构，我发现setup.py很难维护，还不如用autotools了。
好，这次一定要征服autotools。
以前看过乱七八糟的教程，因此只懂了点皮毛。
后来学习过其他东西，知道学习还是看官方文档比较好。特别是Django的官方文档，质量是相当OK的。所以这次也看Autotools的官方文档了。
先从Automake学起，看的是GNU Automake官方文档：
http://www.gnu.org/software/automake/manual/index.html
虽然是英文的，不过现在已经能比较流畅的看下去了。
大概看了十几页，真是相见悢晚啊！
刚开始看其他教程，写的不怎么样，加上Autotools确实有点难学，没学好，还产生了一些厌恶和抵触感，现在看了官方文档，Wow！Automake原来是这么用的，真是很好很强大！
开始对它感兴趣了，所以我相信这次一定能征服它了！
看完Automake后，再看Autoconf、Libtool之类的，GNU的文档也是非常详细的！
不知道来不来的及，我要在Ubuntu 8.10发布前释出最新的Ubuntu Tweak，抓紧时间吧！
最近好像很多项目的build system都在向cmake迁移，特别是大项目，因为autotools的通用性虽然强，但是性能实在是弱项。
@palxex
确实有看到这个迹象，目前为止我了解有KDE 4迁移向了CMake，还有Compiz将要迁移到CMake，不知道还有什么工程？
相对来说，使用Autotools的还是占了绝大多数。
@TualatriX
嗯，的确是如此，大部分项目的”迁移”只是增加了cmake这类选项而已，真正抛弃autotools的并不多。只有代码量和feature都足够复杂以致configure足够慢的，才会真正迁移向cmake这类新预build系统。其实俺只见了allegro库在迁移啦。
autotools本质上是在shell上增补特性(为什么不容易学？就是因为它的出现完全是用户驱动的，make催生configure,configure催生autoconf，autoconf催生automake……也可以说是补丁式的？)，最终的探测过程还是configure这个脚本执行，这也是autotools灵活性的源泉。但是shell的特性决定了它的串行化、解释化，因而性能有不足是可以预期的。cmake这类实际上是对编译前系统特性探测这块做了make当年对源文件做过的事。
想想portage以前也是shell写的，现在好像主体是python了吧。应该是差不多的演进过程。
@palxex
allegro？以前从未听说过。寡闻了。呵呵。
嗯，据说Gentoo刚开始只是用Shell的，后来用Python来做更复杂的后端处理了，不过Bash还是主要一部分。毕竟Ebuild都是Bash写的。
俺的理解: kde4之类转向cmake最大的原因倒不是因为autotools的性能问题, 而是autotools实在太「难」了, 对于大的project维护起来相当困难