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


游戏人生 != ( 人生 == 游戏 )
posts - 62, comments - 508, trackbacks - 0, articles - 7


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


Writen by Fox(



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


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







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

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

o make:编译、链接;

o make install:安装;

o ldconfig:配置环境变量。


Autoconf 流程
Autoconf 流程


写个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.


# Checks for programs.

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.


o mv configure.scan改名;

O emacs编辑


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

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


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

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

o automake --add-missing。






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

2009-12-23 08:15 by jacky

# 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?

First and foremost, your 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).

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

2009-12-24 10:31 by 饭中淹

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

2009-12-24 10:52 by Fox

【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理