• <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>
            Creative Commons License
            本Blog采用 知識(shí)共享署名-非商業(yè)性使用-禁止演繹 3.0 Unported許可協(xié)議 進(jìn)行許可。 —— Fox <游戲人生>

            游戲人生

            游戲人生 != ( 人生 == 游戲 )
            站點(diǎn)遷移至:http://www.yulefox.com。請(qǐng)訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox
            posts - 62, comments - 508, trackbacks - 0, articles - 7

            Autotools初體驗(yàn)

            Posted on 2009-12-23 02:18 Fox 閱讀(6930) 評(píng)論(5)  編輯 收藏 引用 所屬分類: T技術(shù)碎語(yǔ)

            本文同步自游戲人生

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


            從接觸和使用make以來(lái),前前后后寫了不少M(fèi)akefile(添添減減、修修補(bǔ)補(bǔ),累計(jì)上千行是有的),今天在重新整理代碼的組織結(jié)構(gòu)之后,突然就想:我為什么不使用Autotools呢?

            在開(kāi)始體驗(yàn)功能強(qiáng)大的Autotools之前,簡(jiǎn)單(詳細(xì))回憶總結(jié)一下我使用make的經(jīng)歷和思考的過(guò)程,反省一下看看自己在接觸這些新鮮事物的時(shí)候到底走了多少?gòu)澛贰?/p>

            o Cygwin

            今年3月份,拜Kevin Lynx所賜,每次對(duì)Linu淺嘗輒止的我終于下決心接觸了Cygwin環(huán)境,并一發(fā)不可收拾。

            剛開(kāi)始的時(shí)候,就像大學(xué)剛接觸編程那樣,寫“hello, world”,在終端用gcc命令直接編譯,然后開(kāi)始寫最簡(jiǎn)單的只有一個(gè)all的Makefile。因?yàn)镋macs、GCC、make對(duì)我來(lái)說(shuō)都是嶄新的 工具,后面重心就不是放在寫代碼上了,而是急于掌握他們,以求達(dá)到在Windows下的開(kāi)發(fā)效率。

            去年11月底,當(dāng)時(shí)還沒(méi)有開(kāi)始用Cygwin,就買了一本《Managing Projects with GNU Make》,此時(shí)也算物盡其用了。慢慢開(kāi)始使用variables、macros、phony targets、functions,按步就班的系統(tǒng)學(xué)習(xí)應(yīng)用。

            o Ubuntu

            磨磨蹭蹭過(guò)了半年,其間因?yàn)槊χ厴I(yè),對(duì)Cygwin和Emacs、GCC、make也算比較熟悉了。

            今年10月份,開(kāi)始使用Ubuntu,剛開(kāi)始在Windows下用wubi安裝,很快就直接用新的硬盤分區(qū)物理安裝,并隨著Ubuntu 9.10的發(fā)布,升級(jí)到了9.10

            這前后寫Makefile最大的區(qū)別就是,之前純粹是為了寫而寫,之后是為了用而寫。

            隨著整個(gè)代碼結(jié)構(gòu)的不斷膨脹和修改,Makefile也不斷的變化。

            Makefile自身的最大變化是從之前的因?yàn)榫帉戝e(cuò)誤、通用性差而不斷修改,演變到最后代碼增減不會(huì)影響Makefile,只是為了增加tags、優(yōu)化結(jié)構(gòu)而改動(dòng)。

            經(jīng)歷了這個(gè)過(guò)程后,對(duì)于Makefile的結(jié)構(gòu)就比較熟悉了,而且可以從其他使用automake的項(xiàng)目的Makefile中學(xué)習(xí)借鑒了。


            之所以想到使用autotools,是因?yàn)榻佑|的很多開(kāi)源項(xiàng)目的代碼都使用了這一組工具。

            對(duì)于用戶而言,一般的項(xiàng)目編譯安裝的過(guò)程:

            o bootstrap:檢測(cè)autoconfautomakelibtool及其版本并完成初始化,生成configure;

            o configure:檢測(cè)系統(tǒng)平臺(tái)及軟硬件環(huán)境,確定適用本地環(huán)境的編譯策略,生成Makefiles;

            o make:編譯、鏈接;

            o make install:安裝;

            o ldconfig:配置環(huán)境變量。

            對(duì)于開(kāi)發(fā)者而言,則需要通過(guò)autoconf、automake為用戶組織起上面的過(guò)程:

            Autoconf 流程
            Autoconf 流程

            對(duì)于這一流程,我的方法是照葫蘆畫(huà)瓢,參考OGRE等項(xiàng)目的相關(guān)文件和工具的GNU文檔。

            寫個(gè)Hello, Kitty。

            操作的流程和期間出現(xiàn)的幾個(gè)問(wèn)題總結(jié)一下:

            o cd project_dir:轉(zhuǎn)到項(xiàng)目目錄;

            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])

            # 這個(gè)是自動(dòng)生成的,因?yàn)榇a中沒(méi)有相關(guān)初始化信息,這里手動(dòng)修改一下,非必要
            AC_INIT([CgFox], [0.0.1], [http://www.yulefox.com])

            # 這個(gè)是必須的,否則無(wú)法生成aclocal.m4
            AM_INIT_AUTOMAKE([CgFox], 0.0.1)

            AC_CONFIG_SRCDIR([Hello.cpp])

            o aclocal:生成aclocal.m4(太長(zhǎng)了,還沒(méi)去仔細(xì)了解)和autom4te.cache;

            o autoconf:生成configure(也很長(zhǎng),先不看);

            o automake --add-missing。

            ……


            本來(lái)想等明天(今天)弄完了再詳細(xì)整理一下。不過(guò)我沒(méi)有打算把這個(gè)東西搞成一篇教程。記下來(lái)更多的只是為了給自己留下一個(gè)lable,知道自己這幾天在做什么。

            最近又是兩點(diǎn)左右睡。腦子里有個(gè)家伙告訴我這樣不好;另一個(gè)家伙告訴我他還不困;還一個(gè)家伙告訴我明天還要上班。

            我去你大爺?shù)模?/p>

            Feedback

            # re: Autotools初體驗(yàn)[未登錄](méi)  回復(fù)  更多評(píng)論   

            2009-12-23 08:15 by jacky
            autotools用起來(lái)太繁瑣,OGRE已經(jīng)用cmake來(lái)構(gòu)建了,很好用。

            # re: Autotools初體驗(yàn)  回復(fù)  更多評(píng)論   

            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).
            ---------------------------
            當(dāng)然這些問(wèn)題對(duì)于我不是必需的,不過(guò)還是等我autotools用一段時(shí)間再說(shuō):)

            # re: Autotools初體驗(yàn)  回復(fù)  更多評(píng)論   

            2009-12-24 10:31 by 飯中淹
            這個(gè)相對(duì)于IDE來(lái)說(shuō),有什么優(yōu)勢(shì)?

            # re: Autotools初體驗(yàn)  回復(fù)  更多評(píng)論   

            2009-12-24 10:52 by Fox
            @飯中淹
            這套工具現(xiàn)在對(duì)于我更多的是一個(gè)學(xué)習(xí)和試驗(yàn),如果希望和別人交流和共同開(kāi)發(fā)跨平臺(tái)(尤其是non-win)的代碼的話,由于需要對(duì)依賴庫(kù)進(jìn)行檢測(cè),這個(gè)工作可以由autoconf+automake來(lái)完成。
            国色天香久久久久久久小说 | 久久香综合精品久久伊人| 四虎影视久久久免费| 亚洲欧美一区二区三区久久| 中文字幕热久久久久久久| 99久久99久久久精品齐齐| 国内精品久久久久影院网站| 久久中文字幕人妻丝袜| 久久99精品久久久久久| 久久中文字幕人妻熟av女| 欧美综合天天夜夜久久| 国产精品久久新婚兰兰| 7国产欧美日韩综合天堂中文久久久久| 久久久久久久国产免费看| 久久香蕉国产线看观看精品yw| 国产精品熟女福利久久AV| 久久亚洲精品成人AV| 久久受www免费人成_看片中文| 久久香蕉国产线看观看乱码| 一本一本久久aa综合精品| 久久久久九国产精品| 国产精品九九久久免费视频 | 久久久噜噜噜久久| 久久久久国产精品| 亚洲AV无码成人网站久久精品大| 国产精品九九久久免费视频 | 9久久9久久精品| 久久久一本精品99久久精品66| 亚洲国产综合久久天堂| 久久性精品| 婷婷久久综合| 超级97碰碰碰碰久久久久最新| 99久久综合狠狠综合久久| 久久久久综合网久久| 欧美激情精品久久久久| 国产午夜福利精品久久| 国产AV影片久久久久久| 久久久久国产一区二区| 中文字幕精品无码久久久久久3D日动漫 | 香蕉久久夜色精品国产尤物| 欧美大战日韩91综合一区婷婷久久青草|