編譯APR的第一個步驟就是獲取APR開發包。通常情況下，你可以到APR的官方網站http://apr.apache.org/download.cgi去下載。

一般情況下，APR開發包很輕易理解為僅僅是一個開發包，不過事實上并不是。目前，完整的APR實際上包含了三個開發包：apr、apr-util以及apr-iconv，每一個開發包分別獨立開發，并擁有自己的版本。

apr開發包位于目錄${APR}/apr下，其中包含了一些通用的開發組件，包括mmap，文件等等，前面已經描述過。

apr-util開發包位于目錄${APR}/apr-util下，該目錄中也是包含了一些常用的開發組件。這些組件與apr目錄下的相比，它們與apache的關系更加密切一些。比如存儲段和存儲段組，加密等等，具體的各個組件的含義如下表所示：

bUCkets

/srclib/apr-util/buckets

存儲段和存儲段組

crypto

/srclib/apr-util/crypto

加密和解密

hooks

/srclib/apr-util/hooks

apache掛鉤

dbd

/srclib/apr-util/dbd

數據庫連接治理

dbm

/srclib/apr-util/dbm

 

ldap

/srclib/apr-util/ldap

輕量級目錄訪問協議

strmatch

/srclib/apr-util/strmatch

字符串匹配，包括普通字符串匹配以及正則表達式匹配，正則表達式匹配中使用prec庫

uri

/srclib/apr-util/uri

uri操作例程

/srclib/apr-util/xml

xml支持例程，其中使用eXPat作為xml解析器

xlate

/srclib/apr-util/xlate

i18n 轉換庫

encoding

/srclib/apr-util/encoding

編碼轉換庫，其中實現了各種編碼之間的轉換

misc

/srclib/apr-util/misc

大雜燴

apr-util的當前版本為1.2.2，最早的版本為0.9.1。

apr-iconv包中的文件主要用于實現iconv編碼。目前的大部分編碼轉換過程都是與本地編碼相關的。在進行轉換之前必須能夠正確地設置本地編碼。因此假如兩個非本地編碼A和B需要轉換，則轉換過程大致為A->Local以及Local->B或者B->Local以及Local->A。

XPG2 標準中另外定義了一組全新的函式接口ICONV，該接口是一種更廣義的字集轉換系統。也是一個與本地編碼無關的字集轉換系統。APR中也支持這種字集轉換系統，為此它提供了完整的實現。Apr-iconv正是為此目的而產生。

apr-iconv的當前版本為1.1.1，最早的版本從0.9.2開始。

從http://www.apache.org/上下載apr-1.1.1.tar.gz到本地解壓后，可以發現APR的目錄結構很清楚。

1) 所有的頭文件都放在$(APR)/include目錄中;

2) 所有功能接口的實現都放在各自的獨立目錄下，如threadproc、mmap等目錄中，而這些目錄的子目錄中包含實際的實現代碼。Apache中劃分子目錄的根據就是編譯代碼所在的平臺，目前APR能夠支持Unix、BeOS、Windows以及OS2四種平臺，因此正常情況下，每一個目錄中會包含這四個子目錄。比如文件I/O的目錄就如下所示：

apr

 

   -> file_io

         

           -> unix            The Unix and common base code

          

           -> win32           The Windows code

         

           -> os2             The OS/2 code

在上面的四種子目錄中，unix是一個比較非凡的目錄。由于Unix的種類很多，比如FreeBSD，linux等等，原則上應該都為這些平臺分別建立各自的子目錄，然后分別實現代碼。不過所有的Unix都大同小異，假如為了稍許的差異就“大動干戈”，不太劃算，因此APR中將所有的Unix的平臺的操作合并到一起，而這些平臺這些的差異就用前面的預定義宏來區別。目前的unix目錄中以POSIX為主，同時兼顧System V。上面的文件I/O操作中明顯的缺少了BeOS平臺的實現，那是因為BeOS的實現合并到Unix目錄中去了。

另外兩個非凡的目錄就是include和test目錄了。include目錄中包含了所有的外部使用所需要的頭文件。其中APR.h和apr_private.h是兩個非凡的文件，假如要使用APR，必須包含apr.h頭文件。但在原文件中并看不到這兩個文件。事實上，這兩個文件都是自動生成的。由于windows和netware平臺下并不使用autoconf，因此APR在windows和netware平臺下的行為與其余所有平臺都不相同。在UNIX上，apr_private.h(APR私有文件，僅僅APR內部使用)和apr.h(APR公共文件，可以其余的文件使用)實際上在代碼中并不存在，它們都是由autoconf從acconfig.h和apr.h.in中自動生成的。而在Window中，這兩個文件都由apr_private.hw(apr_private.hwn)和apr.hw(apr_private.hwn)中自動生成。

test則是測試程序的目錄。每一個APR類型在使用之前都必須經過測試。事實上對于APR的使用者而言，這個目錄還有另外的一個好處，就是快速把握APR類型的使用。每一個測試例子都給出了具體類型的使用方法。

3) 此外就是相關平臺構建工具文件如Makefile.in，configure.in等等。

在Window和Unix上編譯APR的方法不太相同，我們分開來描述。

We've attempted to ensure that compiling apr, apr-iconv and apr-util distribution tarballs requires nothing more than what comes installed by default on various UNIX platforms.

All you should have to do is this:

   ./configure

   make

   make install

As of this writing, APR is not quite ready to be installed as a system-wide shared library; it currently works best when tied directly to the application using it.

Note that if you are compiling directly from the SVN repository, you'll need GNU autoconf and GNU liBTool installed, and you'll need to run ./buildconf before running the commands listed above.

The apr-util/aprutil.dsw workspace builds the .dsp projects of the Apache server listed with dependent projects preceeding their dependencies:

apr-util/aprutil.dsp

apr-util/libaprutil.dsp

apr-util/uri/gen_uri_delims.dsp

apr-util/xml/expat/lib/xml.dsp

apr-iconv/apriconv.dsp

apr-iconv/libapriconv.dsp

apr/apr.dsp

apr/libapr.dsp

The libXXX projects create .dll targets, dynamic shared libraries. Their non-libXXX counterparts create static .lib targets.

To compile code for the libraries, the consuming compiliation must include the apr/include and apr-util/include Directories in their include file search paths. To target the static .lib versions of the library, the consuming compiliation must define the macros APR_DECLARE_STATIC and APU_DECLARE_STATIC. This prevents the apr and apr-util symbols from being tagged as __declspec(dllimport), eliminating compiliation warnings and speeding up execution.

 

在Window平臺上要成功編譯apr、apr-iconv以及apr-util，必須具備一下的幾個條件：

1)、可用的微軟編譯器：比如微軟的Visual C++ 5.0或者更高的版本，比如Visual C++6.0，Microsoft Visual Studio.NET 2002，Microsoft Visual Studio.NET 2003(必須具備Visual C++ .NET編譯器)。

對于Visual C++ 5.0的用戶，為了能夠使用一些APR中的新特性，你必須更新Windows平臺開發包(Windows Platform SDK)。對于Visual C++ 6.0則沒有這些多余的事情，因為這些SDK隨Visual C++6.0一起發布了。假如沒有這些新的SDK，使用MSVC++5.0編譯的時候，編譯中會出現大量新特性不支持的警告，甚至完全編譯失敗。至于具體的SDK，你可以到Window的網站上去下載。

目前最近的APR版本是2.2.0，不過你假如使用老一些的APR，比如1.1.1以前，那么你還需要awk。你可以到http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe去下載二進制可執行文件。不過從1.1.1以后的版本就可以省去這個麻煩了。

2)、正確的目錄布局

除了必要的編譯工具之外，APR開發包還必須具備正確地目錄布局。apr，apr-util以及apr-iconv必須同時具備，并且它們必須位于同一目錄之下，比如：

對于發行版本，直接將發行的文件包解壓到指定目錄下即可；而對于開發版本，你必須能夠從subversion中自行檢出，Window平臺下，APR推薦的SVN是TortoiseSVN。

萬事具備，只欠東風?，F在你可以編譯APR了。你可以選擇兩種方式，或者是命令行編譯，或者是使用IDE編譯。

■      命令行方式編譯

使用命令行進行編譯的第一步就是修改vcvars32.bat，通常情況下該文件位于C:/Program Files/Microsoft Visual Studio/VC98/Bin目錄下，其中C:/Program Files/Microsoft Visual Studio/是VC的安裝目錄，它根據安裝目錄的不同會不同。

 "C:/Program Files/DevStudio/VC/Bin/vcvars32.bat"

If necessary, you will also need to prepare the Platform SDK environment:

假如有必要，你還必須預備Platform SDK相關的環境變量，這個通常修改setenv.bat文件就可以實現：

 "C:/Program Files/Platform SDK/setenv.bat"

一旦設置完畢，你首先必須切換到apr-util目錄下，然后簡單的執行下面的指令就可以編譯APR了。

 msdev aprutil.dsw /MAKE /

    apriconv - Win32 Release" /

    apr - Win32 Release" /

    libapr - Win32 Release" /

    gen_uri_delims - Win32 Release" /

    xml - Win32 Release" /

    "aprutil - Win32 Release" /

 

 msdev aprutil.dsw /MAKE /

    libapr - Win32 Release" /

    libapriconv - Win32 Release" /

    gen_uri_delims - Win32 Release" /

    xml - Win32 Release" /

    libaprutil - Win32 Release" /

這兩個命令都可以編譯APR，不過它們的區別就是后一個編譯結果是動態鏈接庫.dll，而前者則是靜態連接庫.lib。不過它們編譯的都是發行版，假如你需要編譯調試版本，只需要簡單的將命令中的”Release”替換為”Debug”即可，這樣，你就可以方便的進行調試了。

For Visual Studio C++ 5.0 command line users: Only the .dsp files are maintained within SVN. Win32 .mak files are NOT maintained in SVN, due to the tremendous waste of reviewer's time. Therefore, you cannot rely on the NMAKE commands above to build revised .dsp project files unless you then export all .mak files yourself from the project.

■      IDE方式編譯

與命令行編譯相比，使用IDE編譯更簡單。事實上，在使用的時候我更傾向于使用IDE進行編譯。：）。不過假如你是那種什么都得挖到底的人，前面的命令行編譯你也可以試試。

IDE編譯，你需要的僅僅是一個dsw工作區aprutil.dsw，它位于apr-util目錄下，該工作區中包含了完整編譯整個APR所需要的所有的.dsp項目文件，以及各個dsp文件之間的依靠關系，以確保它們之間的正確的編譯順序。

打開aprutil.dsw，整個工作區如下圖所示：
點擊查看大圖

從上圖中可以看出，apr-util.dsw工作區中包含了十個dsp工作項目。Apr、apriconv以及aprutil分別對應靜態編譯庫，而libXXX則對應的是動態編譯庫。默認情況下，編譯的是apr項目，不過你可以通過project->Set Active Project選擇你需要編譯的實際項目：

 

編譯后aprXXX項目生成的靜態庫通常位于對應目錄下的LibD目錄中，而libXXX項目生成的動態庫則位于Debug或者Release目錄下，具體取決于當前是發行版本還是調試版本。