Creative Commons License
本Blog采用 知识共享署名-非商业性使用-禁止演绎 3.0 Unported许可协议 进行许可。 —— Fox <游戏人生>

游戏人生

游戏人生 != ( 人生 == 游戏 )
站点迁移至:http://www.yulefox.com。请订阅本博的朋友将RSS修改为http://feeds.feedburner.com/yulefox
posts - 62, comments - 508, trackbacks - 0, articles - 7

Autotools初体验

Posted on 2009-12-23 02:18 Fox 阅读(6849) 评论(5)  编辑 收藏 引用 所属分类: T技术碎语

本文同步自游戏人生

Writen by Fox(yulefox.at.gmail.com)


从接触和使用make以来,前前后后写了不少Makefile(添添减减、修修补补,累计上千行是有的),今天在重新整理代码的组织结构之后,突然就想:我为什么不使用Autotools呢?

在开始体验功能强大的Autotools之前,简单(详细)回忆总结一下我使用make的经历和思考的过程,反省一下看看自己在接触这些新鲜事物的时候到底走了多少弯路。

o Cygwin

今年3月份,拜Kevin Lynx所赐,每次对Linu浅尝辄止的我终于下决心接触了Cygwin环境,并一发不可收拾。

刚开始的时候,就像大学刚接触编程那样,写“hello, world”,在终端用gcc命令直接编译,然后开始写最简单的只有一个all的Makefile。因为Emacs、GCC、make对我来说都是崭新的 工具,后面重心就不是放在写代码上了,而是急于掌握他们,以求达到在Windows下的开发效率。

去年11月底,当时还没有开始用Cygwin,就买了一本《Managing Projects with GNU Make》,此时也算物尽其用了。慢慢开始使用variables、macros、phony targets、functions,按步就班的系统学习应用。

o Ubuntu

磨磨蹭蹭过了半年,其间因为忙着毕业,对Cygwin和Emacs、GCC、make也算比较熟悉了。

今年10月份,开始使用Ubuntu,刚开始在Windows下用wubi安装,很快就直接用新的硬盘分区物理安装,并随着Ubuntu 9.10的发布,升级到了9.10

这前后写Makefile最大的区别就是,之前纯粹是为了写而写,之后是为了用而写。

随着整个代码结构的不断膨胀和修改,Makefile也不断的变化。

Makefile自身的最大变化是从之前的因为编写错误、通用性差而不断修改,演变到最后代码增减不会影响Makefile,只是为了增加tags、优化结构而改动。

经历了这个过程后,对于Makefile的结构就比较熟悉了,而且可以从其他使用automake的项目的Makefile中学习借鉴了。


之所以想到使用autotools,是因为接触的很多开源项目的代码都使用了这一组工具。

对于用户而言,一般的项目编译安装的过程:

o bootstrap:检测autoconfautomakelibtool及其版本并完成初始化,生成configure;

o configure:检测系统平台及软硬件环境,确定适用本地环境的编译策略,生成Makefiles;

o make:编译、链接;

o make install:安装;

o ldconfig:配置环境变量。

对于开发者而言,则需要通过autoconf、automake为用户组织起上面的过程:

Autoconf 流程
Autoconf 流程

对于这一流程,我的方法是照葫芦画瓢,参考OGRE等项目的相关文件和工具的GNU文档。

写个Hello, Kitty。

操作的流程和期间出现的几个问题总结一下:

o cd project_dir:转到项目目录;

o emacs Hello.cpp

#include <iostream>

int main(int argc, char** argv)
{
std::cout << "Hello, Kitty!" << std::endl;
return 0;
}

o autoscan:生成configure.scan

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.64])
AC_INIT([FULL-PACKAGE-NAME], [VERSION], [BUG-REPORT-ADDRESS])
AC_CONFIG_SRCDIR([Hello.cpp])
AC_CONFIG_HEADERS([config.h])

# Checks for programs.
AC_PROG_CXX

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.

AC_OUTPUT

o mv configure.scan configure.in:改名;

O emacs configure.in:编辑configure.in

AC_PREREQ([2.64])

# 这个是自动生成的,因为代码中没有相关初始化信息,这里手动修改一下,非必要
AC_INIT([CgFox], [0.0.1], [http://www.yulefox.com])

# 这个是必须的,否则无法生成aclocal.m4
AM_INIT_AUTOMAKE([CgFox], 0.0.1)

AC_CONFIG_SRCDIR([Hello.cpp])

o aclocal:生成aclocal.m4(太长了,还没去仔细了解)和autom4te.cache;

o autoconf:生成configure(也很长,先不看);

o automake --add-missing。

……


本来想等明天(今天)弄完了再详细整理一下。不过我没有打算把这个东西搞成一篇教程。记下来更多的只是为了给自己留下一个lable,知道自己这几天在做什么。

最近又是两点左右睡。脑子里有个家伙告诉我这样不好;另一个家伙告诉我他还不困;还一个家伙告诉我明天还要上班。

我去你大爷的!

Feedback

# re: Autotools初体验[未登录]  回复  更多评论   

2009-12-23 08:15 by jacky
autotools用起来太繁琐,OGRE已经用cmake来构建了,很好用。

# re: Autotools初体验  回复  更多评论   

2009-12-23 09:04 by Fox
In practice, CMake not only lacks a rich platform tests suite, compared to autoconf, it also lacks a lot of features from automake and libtool.

So why should you not switch an autotools-based project over to CMake?

Tedious
First and foremost, your configure.ac script may be large. Porting to CMake can be a time consuming and not so funnny task when it comes to the long tail.
iconv support missing
There are no standard tests for iconv(), neither for finding the compiler flags, nor whether it takes a const pointer.
pkg-config support broken
pkg-config support is reportedly broken as of cmake 2.4 patch 8.
Exported symbols list not implemented
There are no documented ways to specify the list of exported symbols for a shared libraries, so your libraries will unconditionnaly expose all their non-static APIs (libtool can use a flat list or a regular expression).
C99 compiler check missing
There is no built-in support to enable C99 support in the C compiler.
Objective-C flags not supported
You can add flags for the Objective-C compiler, but they propagate to C compilation as well.
Compiler feature checks missing
There are no built-in checks for any of the C99 features, such as variable-sized arrays, restricted pointers, macros with variable number of arguments, etc. nor for GCCisms.
Monolithic installation prefix
There is only one global installation prefix. So the typical Linux distro cannot set the global prefix to /usr while the system configuration (automake's sysconfdir) would be /etc. Very nice for "downstream" Linux packagers...
Installation paths hard-coding
As a consequence of the single prefix, you need to hard-code all paths from the prefix. Instead of ${docdir}, you need to hard-code ${prefix}/share/doc/${package} (${CMAKE_INSTALL_PREFIX}/share/doc/foobar in CMake parliance) and so on and so forth. BSD porters are going to have fun tweaking the paths manually...
Uninstallation not supported
There is sipport for uninstalling. That is a design choice. You'd better never ever try to install a package straight from the build tree, without a proper packaging system.
Installation testsuite not supported
Since there is no uninstallation, there is no of course no distcheck target either. How often did you get your source tarball right from the first attempt before a new release?
No cross-compilation
There is no documented support for cross-compilation. This is scheduled for a future release.
Limited documentation
Compared to autotools, the documentation feels a bit light. At least, there is a wiki, but that cannot replace a good offline reference.
Limited executable renaming
CMake is not quite as powerful as automake (with program-prefix, program-suffix and program-transform-name) when it comes to on-the-fly executable renaming. This little-known feature of automake can be extremely useful when building an operating system distribution with possibly conflicting executable names from different projects. For instance, it is very conveniant along with the Debian alternatives system.
No source tarball packaging
There is no built-in support for making a tarball (make dist). Some Version Control Systems can do it themselves (git does, Subversion does not). This is quite critical a feature for open-source projects.
No source tarball testing
As there is no replacement for make dist, there is no replacement for make distcheck either. From my not-so-humble experience, that is tremendously useful before doing a new release. (NOTE: when I write distcheck, I mean distcheck. I don't mean check which becomes test with CMake)
No gettext integration
Gettext is not supported. Targets for .po and .mo files must be added manually. Nevermind that this is the most widely used localization subsystem in the open-source community.
Awkward feature listing
Whereby ./configure --help gives the list of build option, cmake --help prints the CMake options only. Instead, it seems you have to run cmake in "interactive" mode and answer a question for each and every setting (much like Linux kernel make config).
---------------------------
当然这些问题对于我不是必需的,不过还是等我autotools用一段时间再说:)

# re: Autotools初体验  回复  更多评论   

2009-12-24 10:31 by 饭中淹
这个相对于IDE来说,有什么优势?

# re: Autotools初体验  回复  更多评论   

2009-12-24 10:52 by Fox
@饭中淹
这套工具现在对于我更多的是一个学习和试验,如果希望和别人交流和共同开发跨平台(尤其是non-win)的代码的话,由于需要对依赖库进行检测,这个工作可以由autoconf+automake来完成。

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理