青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

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 閱讀(6954) 評論(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:檢測autoconf、automakelibtool及其版本并完成初始化,生成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來完成。
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久久噜久噜久久综合| 性色av一区二区三区在线观看| 国产欧美日韩免费| 蜜桃久久精品乱码一区二区| 99热在线精品观看| 日韩视频在线观看一区二区| 欧美黄色aaaa| 亚洲黄色影院| 亚洲国产精品悠悠久久琪琪 | 午夜精品久久久久久久白皮肤 | 久久激情网站| 久久9热精品视频| 久久深夜福利| 美日韩丰满少妇在线观看| 欧美日韩一区二区免费视频| 玖玖国产精品视频| 欧美顶级少妇做爰| 欧美体内she精视频| 国产欧美一区二区三区另类精品| 国产精品青草久久| 在线成人小视频| 亚洲一区二区三区777| 久久九九有精品国产23| 亚洲丰满少妇videoshd| 亚洲私人影吧| 久久男人资源视频| 欧美视频精品一区| 亚洲精品一区二区三区四区高清| 亚洲免费在线| 亚洲国产婷婷香蕉久久久久久| 亚洲专区免费| 欧美色视频在线| 亚洲人成人99网站| 老司机午夜精品视频在线观看| 亚洲精品免费在线| 久久久国产一区二区| 国产精品入口| 小黄鸭精品aⅴ导航网站入口 | 国产一区二区三区在线播放免费观看| 国产精品入口尤物| 亚洲视频在线二区| 欧美sm视频| 蜜臀av性久久久久蜜臀aⅴ| 国产偷久久久精品专区| 香蕉av777xxx色综合一区| 亚洲美女淫视频| 欧美日韩精品一区二区在线播放| 免费亚洲电影在线| 亚洲欧美卡通另类91av| 欧美午夜久久久| 欧美中文字幕在线视频| 欧美综合二区| 日韩视频一区二区三区| 99精品欧美| 好看不卡的中文字幕| 欧美国产日本韩| 欧美午夜免费影院| 久久午夜电影网| 久久午夜视频| 午夜精品免费视频| 老司机一区二区| 亚洲一区二区三区久久| 欧美一区三区三区高中清蜜桃| 亚洲国产高清在线| 亚洲欧美色婷婷| 亚洲精品三级| 久久夜色精品国产噜噜av| 亚洲一区二区精品视频| 麻豆视频一区二区| 久久久噜噜噜久久久| 国产精品多人| 日韩一级黄色av| 亚洲美女精品成人在线视频| 久久av最新网址| 亚洲欧美中文在线视频| 欧美日韩国产三级| 欧美国产精品一区| 亚洲高清视频一区二区| 久久国产加勒比精品无码| 欧美在线资源| 国产一区二区视频在线观看| 亚洲一区二区高清| 欧美一区二区播放| 国产伦精品一区二区三区高清版| 亚洲区一区二| 欧美视频二区36p| 亚欧成人在线| 久久综合久久88| 亚洲精品国精品久久99热一| 麻豆精品在线视频| 在线亚洲观看| 亚洲二区在线视频| 免费观看久久久4p| 日韩午夜av电影| 欧美四级在线| 久久精品午夜| 日韩视频一区二区三区在线播放 | 亚洲欧美日韩精品久久奇米色影视 | 欧美黑人在线播放| 亚洲麻豆av| 国产日韩精品视频一区二区三区| 久久精品在线播放| 一区二区三区免费网站| 久久久久久高潮国产精品视| 亚洲激情网站| 激情av一区| 国产精品久久久久7777婷婷| 久久久美女艺术照精彩视频福利播放| 亚洲精品色图| 亚洲国产三级| 欧美成年人视频| 久久琪琪电影院| 久久激情综合| 久久精品国产亚洲精品| 性欧美激情精品| 午夜日韩电影| 欧美亚洲视频在线观看| 午夜一区二区三区在线观看| 亚洲欧美日韩直播| 亚洲免费久久| 一本色道久久综合亚洲精品按摩 | 亚洲视频在线一区观看| 91久久久久久久久| 亚洲精品午夜精品| 亚洲精品视频在线看| 亚洲国产精品一区二区尤物区| 久久综合一区二区| 亚洲国产成人精品久久久国产成人一区 | 红桃av永久久久| 黄色av成人| 日韩网站在线| 亚洲免费在线看| 久久久久99| 欧美福利一区| 亚洲五月六月| 免费一级欧美在线大片| 欧美日韩国产成人在线| 国产精品高精视频免费| 1024国产精品| 亚洲欧美日韩综合一区| 欧美激情第五页| 亚洲综合日韩在线| 久久色在线观看| 国产精品久久午夜夜伦鲁鲁| 韩国一区二区在线观看| 亚洲色图制服丝袜| 亚洲电影第三页| 久久久久九九九九| 国产视频一区三区| 亚洲欧美日韩国产一区二区三区| 欧美尤物一区| 亚洲图片你懂的| 中日韩男男gay无套| 亚洲人成网站在线播| 亚洲欧美一区二区视频| 欧美激情综合网| 在线观看成人网| 久久久久国内| 欧美一区成人| 精品不卡在线| 欧美国产日韩a欧美在线观看| 欧美亚洲一区| 精品88久久久久88久久久| 久久久久久久一区二区| 欧美有码在线观看视频| 精品1区2区3区4区| 久久在线91| 欧美高清视频在线| 亚洲午夜久久久久久久久电影院 | 国产日韩一区二区| 欧美在线观看你懂的| 亚洲日韩成人| 亚洲欧美成人精品| 亚洲日本成人网| 在线亚洲欧美专区二区| 国产日韩欧美视频在线| 女同性一区二区三区人了人一| 男人的天堂成人在线| 亚洲一二三四久久| 久久成人羞羞网站| av不卡免费看| 裸体歌舞表演一区二区| 午夜精品福利一区二区三区av | 一区二区三区四区国产| 国产欧美亚洲视频| 亚洲精品久久久久久久久久久| 国产精品亚洲激情| 亚洲精品在线观看免费| 亚洲韩国青草视频| 欧美主播一区二区三区美女 久久精品人 | 国产精品视频福利| 亚洲美女电影在线| 99国产成+人+综合+亚洲欧美| 久久国产色av| 欧美中在线观看| 国产丝袜美腿一区二区三区| 亚洲一区二区在线视频| 亚洲性夜色噜噜噜7777| 欧美成人亚洲成人| 亚洲日本成人|