【轉】Application.mk 檔案文法規範

標籤：

原文網址：http://blog.sina.com.cn/s/blog_4c451e0e0100s6q4.html

Application.mk file syntax specificationApplication.mk 檔案文法規範 Introduction:介紹：------------- This document describes the syntax of Application.mk build fileswritten to describe the native modules required by your Androidapplication. To understand what follows, it is assumed that you haveread the docs/OVERVIEW.html file that explains their role andusage.本文檔描述了 Application.mk 組建檔案的文法，以及根據你的 Android 應用程式要求描述本機模組。為了理解下面內容，假設你有讀過 docs/OVERVIEW.html 檔案，明白了它們的作用和用法。 Readers of this document should have read docs/OVERVIEW.html anddocs/ANDROID-MK.html本文檔的讀者將有讀過 docs/OVERVIEW.html 和 docs/ANDROID-MK.html Overview:概述：--------- The purpose of Application.mk is to describe which native‘modules‘ (i.e. static/shared libraries) are needed by yourapplication.Application.mk 檔案的目地是來描述被你的應用程式所需要的本機模組(也就是：靜態庫或共用庫)。 An Application.mk file is usually placed under $PROJECT/jni/Application.mk,where $PROJECT points to your application‘s project directory.一個 Application.mk 檔案通常是放置在 $PROJECT/jni/Application.mk 這個路徑下面，$PROJECT 意味著你應用程式的工程目錄。 Another alternative is to place it under a sub-directory of the top-level$NDK/apps directory, e.g.:另一個可放置的地方是在 $NDK/apps 目錄的子目錄下，例如：    $NDK/apps/<myapp>/Application.mk Where <myapp> is a short name used to describe your ‘application‘to the NDK build system (this name doesn‘t go into your generatedshared libraries or your final packages).<myapp>是一個簡短名稱用來為 NDK 產生系統描述你的應用程式(這個名字不會進入你的共用庫或你的最終包)。 The Application.mk is really a tiny GNU Makefile fragment that mustdefine a few variables:Application.mk 實際上是一個極小的 GNU Makefile 片斷，必然要定義幾個變數： APP_PROJECT_PATH    This variable should give the *absolute* path to your    Application‘s project root directory. This is used to copy/install    stripped versions of the generated JNI shared libraries to a    specific location known to the APK-generating tools.    這個變數將提供你應用程式工程根目錄的絕對路徑。    這是用來拷貝或安裝已脫離版本的 JNI 共用庫到一個 APK 產生工具已知的具體位置。     Note that it is optional for $PROJECT/jni/Application.mk, but    *mandatory* for $NDK/apps/<myapp>/Application.mk    注意，對於 $PROJECT/jni/Application.mk 它是可選項的，    　　　但是對於 $NDK/apps/<myapp>/Application.mk 就是強制的了。 APP_MODULES    This variable is optional. If not defined, the NDK will build by    default _all_ the modules declared by your Android.mk, and any    sub-makefile it may include.    這個變數是可選的。    如果沒有定義的話，NDK 將通過預設 _all_ 產生由你的 Android.mk 檔案聲明的所有模組，    並且可以包含任意子 Makefile 檔案。     If APP_MODULES is defined, it must be a space-separated list of module    names as they appear in the LOCAL_MODULE definitions of Android.mk    files. Note that the NDK will compute module dependencies automatically.    如果 APP_MODULES 是定義過的，    它一定是一個空格分隔的模組名列表，就像它們出現在 Android.mk 檔案的 LOCAL_MODULE 定義中一樣。     NOTE: This variable‘s behaviour changed in NDK r4. Before that:    注意：這個變數的行為方式已在 NDK r4 中改變。之前是：       - the variable was mandatory in your Application.mk      - 該變數在你的 Application.mk 檔案中是強制的。      - all required modules had to be listed explicitly.      - 全部需要的模組已明確地列出。 APP_OPTIM    This optional variable can be defined to either ‘release‘ or    ‘debug‘. This is used to alter the optimization level when    building your application‘s modules.    這個可選的變數可以定義 發行版 或 調試版 。    這是用來在產生你應用程式的模組時改變最佳化層級。     A ‘release‘ mode is the default, and will generate highly    optimized binaries. The ‘debug‘ mode will generate un-optimized    binaries which are much easier to debug.    發行版 模式是預設的，並且將產生高度地最佳化二進位代碼。    調試版 模式將產生未最佳化的二進位代碼，讓調試更容易些。     Note that if your application is debuggable (i.e. if your manifest    sets the android:debuggable attribute to "true" in its <application>    tag), the default will be ‘debug‘ instead of ‘release‘. This can    be overridden by setting APP_OPTIM to ‘release‘.    注意如果你的應用程式是可調試的    (也就是：如果你的 manifest 在它的 <application> 標籤中 設定 android:debuggable 屬性為 true )，    調度版 模式將替代 發行版 模式成為預設。    這可以通過設定 APP_OPTIM 為 release 來不理會。     Note that it is possible to debug both ‘release‘ and ‘debug‘    binaries, but the ‘release‘ builds tend to provide less information    during debugging sessions: some variables are optimized out and    can‘t be inspected, code re-ordering can make stepping through    the code difficult, stack traces may not be reliable, etc...    注意 發行版 模式 和 調試版 模式都可做調式，但是 發行版 模式在調試作業階段提供較少的資訊：    一些變數是被最佳化掉了不能被視察了，代碼再排序讓單步調試困難，堆疊追蹤不可信賴，等等。 APP_CFLAGS    A set of C compiler flags passed when compiling any C or C++ source code    of any of the modules. This can be used to change the build of a given    module depending on the application that needs it, instead of modifying    the Android.mk file itself.    一組 C 編譯器的標誌在編譯任意模組的任何 C 或 Ｃ++ 原始碼時被傳遞。    這可以是應用程式視情況而定來改變特定模組的產生。     IMPORTANT WARNING:     重要警告：    +++++++++++++++++++++++++++++++++++++++++++++++++++    +    + All paths in these flags should be relative to the top-level NDK    + directory. For example, if you have the following setup:    + 在這些標誌中的全部路徑將是相對於頂級 NDK 目錄。例如，如果你有如下結構：     +    +    sources/foo/Android.mk    +    sources/bar/Android.mk    +    +  To specify in foo/Android.mk that you want to add the path to the    + ‘bar‘ sources during compilation, you should use:    + 在 foo/Android.mk 檔案中具體指定你想要在編譯時間期添加 bar 源檔案路徑，你將使用：    +    +   APP_CFLAGS += -Isources/bar    +    + Or alternatively:     + 或者：    +    +   APP_CFLAGS += -I$(LOCAL_PATH)/../bar    +    + Using ‘-I../bar‘ will *NOT* work since it will be equivalent to    + ‘-I$NDK_ROOT/../bar‘ instead.    + 使用 -I../bar 將沒有效，因為它將相當於 -I$NDK_ROOT/../bar 。    +    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++     NOTE: In android-ndk-1.5_r1, this only applied to C sources, not C++ ones.          This has been corrected to match the full Android build system.    注意：在 android-ndk-1.5_r1 中，這僅適用於 C 源檔案，而沒有 C++ 編譯標誌一個。    　　　這已經改正徹底地匹配 Android 產生系統。 APP_CXXFLAGS    An alias for APP_CPPFLAGS, to be considered obsolete as it may disappear    in a future release of the NDK.    一個 APP_CPPFLAGS 的別名，在未來 NDK 的發行版中考慮到過時的原因，它可能會消失。 APP_CPPFLAGS    A set of C++ compiler flags passed when building C++ sources *only*.    一組 C++ 編譯器的標誌僅在產生 C++ 源檔案時被傳遞。     NOTE: In android-ndk-1.5_r1, this applied to both C and C++ sources.          This has been corrected to match the full Android build system.          You can now use APP_CFLAGS for flags that shall apply to C and          C++ sources.    注意：在 android-ndk-1.5_r1 中，這適用於 C 和 C++ 兩者的源檔案。    　　　這已經改正徹底地匹配 Android 產生系統。    　　　你可以現在使用 APP_CFLAGS 變數，將適用於 C 和 C++ 源檔案。 APP_BUILD_SCRIPT    By default, the NDK build system will look for a file named Android.mk    under $(APP_PROJECT_PATH)/jni, i.e. for the file:    預設情況下，NDK 產生系統將尋找一個名為 Android.mk 檔案在 $(APP_PROJECT_PATH)/jni 目錄下，    也就是，如此檔案：        $(APP_PROJECT_PATH)/jni/Android.mk     If you want to override this behaviour, you can define APP_BUILD_SCRIPT    to point to an alternate build script. A non-absolute path will always    be interpreted as relative to the NDK‘s top-level directory.    如果你想要替代這個行為方式，你可以定義 APP_BUILD_SCRIPT 來指出一個供替換的產生指令碼。    一個非絕對路徑將一直是被解釋為相對於 NDK 頂級目錄。 APP_ABI    By default, the NDK build system will generate machine code for the    ‘armeabi‘ ABI. This corresponds to an ARMv5TE based CPU with software    floating point operations. You can use APP_ABI to select a different    ABI.    預設情況下，NDK 產生系統將產生適用於 armeabi ABI 機器碼。    這符合一個基於 ARMv5TE 的 CPU 對應軟體浮點操作。    你可以使用 APP_ABI 來選擇一個不同的 ABI 。     For example, to support hardware FPU instructions on ARMv7 based devices,    use:    例如，對於支援硬體 FPU 指令在基於 ARMv7 的裝置上，使用：         APP_ABI := armeabi-v7a     Or to support both ARMv5TE and ARMv7 based devices, use:    或對於基於 ARMv5TE 和 ARMv7 兩者都支援的裝置，使用：         APP_ABI := armeabi armeabi-v7a     For the list of all supported ABIs and details about their usage and    limitations, please read docs/CPU-ARCH-ABIS.html    對於全部支援的 ABI 列表和詳細說明關於它們的用法與限制，請閱讀 read docs/CPU-ARCH-ABIS.html APP_STL    By default, the NDK build system provides C++ headers for the minimal    C++ runtime library (/system/lib/libstdc++.so) provided by the Android    system.    預設情況下，NDK 產生系統為由 Android 系統提供的最低限度的 C++ 執行階段程式庫(/system/lib/libstdc++.so)提供標頭檔。     However, the NDK comes with alternative C++ implementations that you can    use or link to in your own applications. Define APP_STL to select one of    them. Examples are:    然而，NDK 提供任你選擇的 C++ 實現，你可以使用或鏈入你的應用程式中。    定義 APP_STL 來選擇它們中的一個。例如：        APP_STL := stlport_static    --> static STLport library       APP_STL := stlport_shared    --> shared STLport library       APP_STL := system            --> default C++ runtime library     For more information on the subject, please read docs/CPLUSPLUS-SUPPORT.html    就此話題的更多資訊，請閱讀 docs/CPLUSPLUS-SUPPORT.html A trivial Application.mk file would be:一個普通的 Application.mk 檔案將是： -------------- cut here -------------------------APP_PROJECT_PATH := <path to project>-------------- cut here -------------------------

【轉】Application.mk 檔案文法規範