其他章節(jié)的翻譯請(qǐng)參見(jiàn)：
http://blog.csdn.net/column/details/gradle-translation.html
翻譯項(xiàng)目請(qǐng)關(guān)注Github上的地址：
https://github.com/msdx/gradledoc
本文翻譯所在分支：
https://github.com/msdx/gradledoc/tree/1.12。
直接瀏覽雙語(yǔ)版的文檔請(qǐng)?jiān)L問(wèn)：
http://gradledoc.qiniudn.com/1.12/userguide/userguide.html。
另外，Android 手機(jī)用戶可通過(guò)我寫(xiě)的一個(gè)程序?yàn)g覽文檔，帶緩存功能的，目前0.5版本兼容 Android 2.3以上系統(tǒng)，項(xiàng)目地址如下：
https://github.com/msdx/gradle-doc-apk
翻譯不易，轉(zhuǎn)載請(qǐng)注明本文在CSDN博客上的出處：
http://blog.csdn.net/maosidiaoxian/article/details/55683474

關(guān)于我對(duì)Gradle的翻譯，以Github上的項(xiàng)目及http://gradledoc.qiniudn.com 上的文檔為準(zhǔn)。如發(fā)現(xiàn)翻譯有誤的地方，將首先在以上兩個(gè)地方更新。因時(shí)間精力問(wèn)題，博客中發(fā)表的譯文基本不會(huì)同步修改。

另外，目前Gradle1.12版本的文檔進(jìn)入校稿階段，校稿的方式可以為到該項(xiàng)目https://github.com/msdx/gradledoc 提交issue或是pull request。校稿的結(jié)果不只是在此版本更新，也會(huì)用于改善Gradle下一版本（2.0）文檔的翻譯。

第五十四章. 構(gòu)建原生二進(jìn)制文件

Gradle 對(duì)構(gòu)建原生二進(jìn)制文件的支持目前還是孵化階段。請(qǐng)務(wù)必注意，在以后的 Gradle 版本中，相關(guān)的 DSL 和其他配置可能會(huì)有所改變。

不同的原生二進(jìn)制插件添加了對(duì)從C++，C，Objective-C，Objective-C++以及匯編源文件構(gòu)建原生軟件組件的支持。雖然對(duì)于這種軟件開(kāi)發(fā)的空間，已經(jīng)有許多優(yōu)秀的構(gòu)建工具存在，但是Gradle 向開(kāi)發(fā)人員提供的是它的強(qiáng)大特征和靈活性，以及在依賴管理實(shí)踐上，在JVM開(kāi)發(fā)空間上更為傳統(tǒng)的發(fā)現(xiàn)。

54.1. 工具鏈支持

Gradle 提供了使用不同的工具鏈執(zhí)行相同的構(gòu)建的能力。你可以通過(guò)更改操作系統(tǒng)的PATH讓其包含所需的工具鏈編譯器，來(lái)控制使用哪個(gè)工具鏈。或者，你可以直接配置工具鏈，就如下面的“原生二進(jìn)制變種”中描述的。

支持以下的工具鏈：

操作系統(tǒng)	工具鏈	備注
Linux	GCC	?
Linux	Clang	?
Mac OS X	GCC	使用 XCode 中的 GCC。
Mac OS X	Clang	使用 XCode 中的 Clang。
Windows	Visual C++	Windows XP及以上，Visual C++ 2010 及以上版本。
Windows	GCC	Windows XP及以上，使用Cygwin的GCC。
Windows	MinGW	Windows XP 及以上。

54.2. 組件模型

一個(gè)原生二進(jìn)制project定義了一組Executable和Library組件，每一個(gè)的 Gradle 都映射大量的NativeBinary輸出。對(duì)于每個(gè)定義的executable或library，Gradle 添加了具有相同名稱的FunctionalSourceSet?。這些功能源碼集將為project所支持的每一種語(yǔ)言包含指定語(yǔ)言的源碼集。

為構(gòu)建一個(gè)靜態(tài)或共享的原生庫(kù)二進(jìn)制文件，一個(gè)Library組件將添加到libraries容器中。每個(gè)library組件可以產(chǎn)生至少一個(gè)SharedLibraryBinary和至少一個(gè)StaticLibraryBinary。

示例 54.1. 定義一個(gè)庫(kù)組件

build.gradle

libraries {hello {} }

為構(gòu)建一個(gè)可執(zhí)行的二進(jìn)制，Executable組件添加到executables容器中，并與源碼集相關(guān)聯(lián)。

示例 54.2. 定義可執(zhí)行組件

build.gradle

executables {main {} }

在許多情況下，一個(gè)組件可以產(chǎn)生超過(guò)一個(gè)的原生二進(jìn)制文件。基于構(gòu)建所使用的工具鏈，提供的編譯器/鏈接器標(biāo)志，提供的依賴或其他源文件，這些二進(jìn)制文件可能會(huì)發(fā)生變化。組件所產(chǎn)生的每個(gè)原生二進(jìn)制稱為variant。下面將詳細(xì)討論二進(jìn)制 variant。

54.3. 任務(wù)

針對(duì)由構(gòu)建所產(chǎn)生的每一個(gè)?NativeBinary，我們構(gòu)造了一個(gè)生命周期任務(wù)用于創(chuàng)建二進(jìn)制，以及一系統(tǒng)的其他做實(shí)際工作，如編譯，鏈接或者是裝配二進(jìn)制文件的任務(wù)。

組件類型	原生二進(jìn)制文件類型	生命周期任務(wù)	創(chuàng)建二進(jìn)制文件的位置
Executable	ExecutableBinary	$component.nameExecutable	$buildDir/binaries/$binary.name/$component.name
Library	SharedLibraryBinary	$component.nameSharedLibrary	$buildDir/binaries/$binary.name/lib$component.name.so
Library	StaticLibraryBinary	$component.nameStaticLibrary	$buildDir/binaries/$binary.name/$component.name.a

54.3.1. 使用共享庫(kù)

對(duì)于每個(gè)產(chǎn)生的可執(zhí)行二進(jìn)制文件，?cpp插件提供了install${binary.name}任務(wù)，這個(gè)任務(wù)可以創(chuàng)建該可執(zhí)行文件及它需要的共享庫(kù)的開(kāi)發(fā)安裝。它允許你運(yùn)行可執(zhí)行文件，而無(wú)需在其最終的位置安裝共享庫(kù)。

544.核心語(yǔ)言支持: C、C++、匯編，Objective-C和Objective-C++

目前，Gradle 支持從C++，C，Assembler，Objective-C 和 Objective-C++源碼的任意組合中構(gòu)建原生二進(jìn)制文件。一個(gè)原生二進(jìn)制project 將包含一個(gè)或多個(gè)叫做FunctionalSourceSet的實(shí)例（如"main"，"test"等），其中每一個(gè)都可以包含含有C++，C，Assembler，Objective-C或Objective-C++源代碼的LanguageSourceSets。

54.4.1.?C++ 源代碼

'cpp'?插件提供了C++ 語(yǔ)言的支持。

示例 54.3. cpp 插件

build.gradle

apply plugin: 'cpp'

把 C++ 源碼包含到原生二進(jìn)制文件中，是通過(guò)一個(gè)?CppSourceSet來(lái)實(shí)現(xiàn)的，它定義了一個(gè)C++源文件集以及（可選的）一個(gè)可導(dǎo)出的頭文件（用于library）集默認(rèn)情況下，對(duì)于任何命名的組件，CppSourceSet包含了在src/${name}/cpp中的.cpp源文件，和在src/${name}/headers中的頭文件。

而cpp插件為每個(gè)CppSourceSet定義了這些默認(rèn)的位置，且可以擴(kuò)展或重寫(xiě)這些默認(rèn)值使能夠成為不同的項(xiàng)目布局。

示例 54.4.?C++ 源代碼集

build.gradle

sources {main {cpp {source {srcDir "src/source"include "**/*.cpp"}}} }

對(duì)于名字為“main”的library，?src/main/headers中的文件都被視為"公共"或"導(dǎo)出"的頭文件。不應(yīng)該被導(dǎo)出（而是內(nèi)部使用）的頭文件，應(yīng)該放在?src/main/cpp?目錄（不過(guò)要注意，這樣的文件應(yīng)該總是以相對(duì)于包含它們的文件這樣的一種方式被引用）。

54.4.2.?C 源代碼

'c'?插件提供了C 語(yǔ)言的支持。

示例 54.5. “C” 插件

build.gradle

apply plugin: 'c'

把 C 源碼包含到原生二進(jìn)制文件中，是通過(guò)一個(gè)?CSourceSet來(lái)實(shí)現(xiàn)的，它定義了一個(gè)C源文件集以及（可選的）一個(gè)可導(dǎo)出的頭文件（用于library）集默認(rèn)情況下，對(duì)于任何命名的組件，CSourceSet包含了在src/${name}/c中的.c源文件，和在src/${name}/headers中的頭文件。

而c插件為每個(gè)CSourceSet定義了這些默認(rèn)的位置，且可以擴(kuò)展或重寫(xiě)這些默認(rèn)值使能夠成為不同的項(xiàng)目布局。

示例 54.4.?C 源代碼集

build.gradle

sources {hello {c {source {srcDir "src/source"include "**/*.c"}exportedHeaders {srcDir "src/include"}}} }

對(duì)于名字為“main”的library，?src/main/headers中的文件都被視為"公共"或"導(dǎo)出"的頭文件。不應(yīng)該被導(dǎo)出（而是內(nèi)部使用）的頭文件，應(yīng)該放在?src/main/c?目錄（不過(guò)要注意，這樣的文件應(yīng)該總是以相對(duì)于包含它們的文件這樣一種方式被引用）。

54.4.3.?匯編代碼

“assembler”?插件提供了匯編語(yǔ)言的支持。

示例 54.3. assembler 插件

build.gradle

apply plugin: 'assembler'

把匯編源碼包含到原生二進(jìn)制文件中，是通過(guò)一個(gè)?AssemblerSourceSet來(lái)實(shí)現(xiàn)的，它定義了一個(gè)匯編源文件集。默認(rèn)情況下，對(duì)于任何命名的組件，AssemblerSourceSet包含了在src/${name}/asm中的.s源文件。

54.4.4.?Objective-C 源碼

'objective-c'?插件提供了Objective-C 語(yǔ)言的支持。

示例?54.8.?“objective-c”插件

build.gradle

apply plugin: 'objective-c'

把Objective-C源碼包含到原生二進(jìn)制文件中，是通過(guò)一個(gè)?ObjectiveCSourceSet來(lái)實(shí)現(xiàn)的，它定義了一個(gè)Objective-C源文件集。默認(rèn)情況下，對(duì)于任何命名的組件，ObjectiveCSourceSet包含了在src/${name}/objectiveC中的.m源文件。

54.4.5.?Objective-C++ 源碼

'objective-cpp'?插件提供了Objective-C++ 語(yǔ)言的支持。

示例 54.9. “objective-cpp” 插件

build.gradle

apply plugin: 'objective-cpp'

把Objective-C++源碼包含到原生二進(jìn)制文件中，是通過(guò)一個(gè)?ObjectiveCppSourceSet來(lái)實(shí)現(xiàn)的，它定義了一個(gè)Objective-C++源文件集。默認(rèn)情況下，對(duì)于任何命名的組件，ObjectiveCppSourceSet包含了在src/${name}/objectiveCpp中的.mm源文件。

54.5. 配置編譯器，匯編器和連接器

每一個(gè)產(chǎn)生的二進(jìn)制文件都和一系列的編譯器和鏈接器設(shè)置相關(guān)聯(lián)，這些設(shè)置包含了命令行參數(shù)，以及宏定義。這些設(shè)置可以應(yīng)用于所有的二進(jìn)制文件，單個(gè)二進(jìn)制文件，或選擇性地應(yīng)用于基于某些條件的一組二進(jìn)制文件。

示例 54.10. 應(yīng)用于所有二進(jìn)制文件的設(shè)置

build.gradle

binaries.all {// Define a preprocessor macro for every binarycppCompiler.define "NDEBUG"// Define toolchain-specific compiler and linker optionsif (toolChain in Gcc) {cppCompiler.args "-O2", "-fno-access-control"linker.args "-Xlinker", "-S"}if (toolChain in VisualCpp) {cppCompiler.args "/Zi"linker.args "/DEBUG"} }

每個(gè)二進(jìn)制文件與特定的ToolChain關(guān)聯(lián)，允許設(shè)置基于此值進(jìn)行針對(duì)性的配置。

讓設(shè)置應(yīng)用于指定類型的所有二進(jìn)制文件很簡(jiǎn)單：

示例 54.11. 應(yīng)用于所有共享庫(kù)的設(shè)置

build.gradle

// For any shared library binaries built with Visual C++, define the DLL_EXPORT macro binaries.withType(SharedLibraryBinary) {if (toolChain in VisualCpp) {cCompiler.args "/Zi"cCompiler.define "DLL_EXPORT"} }

此外，還可以指定設(shè)置應(yīng)用于某個(gè)特定的executable?或?library?組件 產(chǎn)生的所有二進(jìn)制文件：

示例 54.12. 應(yīng)用于“main”可執(zhí)行組件所產(chǎn)生的所有二進(jìn)制文件的設(shè)置

build.gradle

executables {main {binaries.all {if (toolChain in VisualCpp) {assembler.args "/Zi"} else {assembler.args "-g"}}} }

上面的例子將會(huì)把提供的配置應(yīng)用到所有構(gòu)建的?executable二進(jìn)制文件。

同樣，也可以為某種特定類型的組件，把設(shè)置指向目標(biāo)二進(jìn)制文件：例如所有main library組件的shared libraries。

示例 54.13. 僅應(yīng)用于“main”library組件所產(chǎn)生的共享庫(kù)的設(shè)置

build.gradle

libraries {main {binaries.withType(SharedLibraryBinary) {// Define a preprocessor macro that only applies to shared librariescppCompiler.define "DLL_EXPORT"}} }

54.6.?Windows Resource

當(dāng)使用VisualCpp工具鏈時(shí)，Gradle 時(shí)能夠編譯Window Resource (rc) 文件并將它們鏈接到本地的二進(jìn)制文件。這個(gè)功能是由'windows-resources'?插件所提供的。

示例?54.14.?'windows-resources' 插件

build.gradle

apply plugin: 'windows-resources'

將 Windows 資源包含進(jìn)本機(jī)二進(jìn)制文件中，是通過(guò)一個(gè)WindowsResourceSet提供的，它定義了一組Windows Resource源文件。默認(rèn)情況下，WindowsResourceSet為所有的命名組件包含了在src/${name}/rc下的.rc源文件。

與其他源文件類型一樣，您可以配置把windows 資源的位置包含進(jìn)二進(jìn)制文件中。

示例 54.15. 配置 Windows 資源源文件的位置

build-resource-only-dll.gradle

sources {helloRes {rc {source {srcDirs "src/hello/rc"}exportedHeaders {srcDirs "src/hello/headers"}}} }

你能夠通過(guò)提供沒(méi)有任何其他語(yǔ)言來(lái)源的 Windows Resource 源文件，來(lái)構(gòu)造純資源庫(kù)，并適當(dāng)?shù)嘏渲面溄悠鳗U

示例 54.16. 構(gòu)建一個(gè)純資源 dll

build-resource-only-dll.gradle

libraries {helloRes {binaries.all {rcCompiler.args "/v"linker.args "/noentry", "/machine:x86"}} }

上面的示例還演示了將額外的命令行參數(shù)傳遞給資源編譯器的機(jī)制。rcCompiler擴(kuò)展是PreprocessingTool類型。

54.7.?庫(kù)依賴

C++ 項(xiàng)目的依賴是導(dǎo)出頭文件的二進(jìn)制庫(kù)。這些頭文件在編譯期間使用，而編譯的二進(jìn)制依賴則在鏈接過(guò)程中使用。

54.7.1.?同一項(xiàng)目的依賴

一組源文件可能依賴于在同一個(gè)項(xiàng)目中由另一個(gè)二進(jìn)制組件提供的頭文件。一個(gè)常見(jiàn)的例子是一個(gè)本地可執(zhí)行組件，使用了由一個(gè)單獨(dú)的本地庫(kù)組件提供的功能。

這樣的庫(kù)依賴可以很方便地提供給source set關(guān)聯(lián)上executable組件。

示例 54.17. 向source set提供庫(kù)依賴

build.gradle

sources {main {cpp {lib libraries.hello}} }

另外，一個(gè)庫(kù)依賴項(xiàng)可以直接提供給ExecutableBinary的executable。

示例 54.18. 向二進(jìn)制文件提供庫(kù)依賴

build.gradle

executables {main {binaries.all {// Each executable binary produced uses the 'hello' static library binarylib libraries.hello.static}} }

54.7.2. 項(xiàng)目依賴

對(duì)于在不同的 Gradle 項(xiàng)目產(chǎn)生的組件，notation是類似的。

示例 54.19. 定義項(xiàng)目依賴

build.gradle

project(":lib") {apply plugin: "cpp"libraries {main {}} }project(":exe") {apply plugin: "cpp"executables {main {}}sources {main {cpp {lib project: ':lib', library: 'main'}}} }

54.8.?本地二進(jìn)制變種

對(duì)于每個(gè)定義的可執(zhí)行文件或庫(kù)，Gradle 能夠構(gòu)建多個(gè)不同的本機(jī)二進(jìn)制變種。這樣的例子包括debug及release的二進(jìn)制文件，32位及64位的二進(jìn)制文件，以及使用不同的自定義預(yù)處理標(biāo)志生成的二進(jìn)制文件。

Gradle 產(chǎn)生的二進(jìn)制文件可以區(qū)分?構(gòu)建類型，?平臺(tái)以及?flavor。對(duì)于這里的每一個(gè)“變種維度”，它可以指定一組可用的值，并且針對(duì)每個(gè)組件使用這里的一個(gè)或多個(gè)或全部的值。例如，一個(gè)插件可以定義一系列的支持平臺(tái)，但你可以選擇某個(gè)特定組件只構(gòu)建Windows-x86平臺(tái)。

54.8.1. 構(gòu)建類型

一個(gè)?build type?確定了一個(gè)二進(jìn)制文件的各種非功能性方面，比如是否包含調(diào)試信息，或者使用什么樣的優(yōu)化級(jí)別來(lái)編譯二進(jìn)制文件。典型的構(gòu)建類型是“debug”和“release”，但一個(gè)project可以自由定義任意的構(gòu)建類型。

示例 54.20. 定義構(gòu)建類型

build.gradle

model {buildTypes {debugrelease} }

如果在project中沒(méi)有定義任何構(gòu)建類型，那么會(huì)有一個(gè)默認(rèn)的“debug”構(gòu)建類型被加進(jìn)去。

對(duì)于一個(gè)構(gòu)建類型，Gradle project 通常會(huì)定義一組每個(gè)工具鏈的編譯器/鏈接器標(biāo)志。

示例 54.21. 配置debug二進(jìn)制文件

build.gradle

binaries.all {if (toolChain in Gcc && buildType == buildTypes.debug) {cppCompiler.args "-g"}if (toolChain in VisualCpp && buildType == buildTypes.debug) {cppCompiler.args '/Zi'cppCompiler.define 'DEBUG'linker.args '/DEBUG'} } 在這個(gè)階段，它就完全符合構(gòu)建腳本來(lái)為每個(gè)構(gòu)建類型配置相關(guān)的編譯器/鏈接器標(biāo)志。未來(lái)版本的 Gradle 將自動(dòng)包括任何“debug”構(gòu)建類型的適當(dāng)調(diào)試標(biāo)志，并且還可能知道各個(gè)優(yōu)化級(jí)別。

54.8.2.?平臺(tái)

通過(guò)為每個(gè)平臺(tái)生成一個(gè)變種，能夠使一個(gè)可執(zhí)行文件或庫(kù)構(gòu)建為可以運(yùn)行在不同的操作系統(tǒng)及CPU架構(gòu)上。Gradle 把每一個(gè)系統(tǒng)架構(gòu)組合定義為一個(gè)?Platform，一個(gè)project可以定義多個(gè)platforms。如果在project里沒(méi)有定義任何平臺(tái)，那么會(huì)添加一個(gè)默認(rèn)的“current”平臺(tái)。

目前，一個(gè)Platform由一個(gè)定義的操作系統(tǒng)和架構(gòu)構(gòu)成。隨著我們繼續(xù)開(kāi)發(fā) Gradle 的本地二進(jìn)制支持，將擴(kuò)展Platform的概念，包括 C-runtime版本，Windows SDK，ABI，等等。復(fù)雜的構(gòu)建，可能使用 Gradle 的擴(kuò)展性來(lái)把附加屬性應(yīng)用到每個(gè)platform中，然后可以查詢?yōu)橐粋€(gè)本地二進(jìn)制包含了哪些特別指定的預(yù)處理器或者是編譯器參數(shù)。

示例 54.22. 定義platform

build.gradle

model {platforms {x86 {architecture "x86"}x64 {architecture "x86_64"}itanium {architecture "ia-64"}} }

對(duì)于給定的變種，Gradle 將嘗試查找能夠構(gòu)建目標(biāo)平臺(tái)的ToolChain。可用的工具鏈將按照定義的順序進(jìn)行查找。更多的細(xì)節(jié)請(qǐng)參閱下面的工具鏈部分。

54.8.3.?Flavor

每個(gè)組件都可以有一組flavors，并且能為每一個(gè)flavor生成一個(gè)單獨(dú)的二進(jìn)制變種。在Gradle中?build type?和?target platform?變種維度是有一個(gè)確定的定義的，而每一個(gè)project都可以自由地定義數(shù)量的flavor并且用任何方式去應(yīng)用它們的意義。

一個(gè)關(guān)于組件flavor的例子是可以區(qū)分組件的“demo”，“paid”和“enterprise”版本，它們都用同樣的源碼來(lái)生成不同功能的二進(jìn)制文件。

示例 54.23. 定義flavors

build.gradle

model {flavors {englishfrench} }libraries {hello {binaries.all {if (flavor == flavors.french) {cppCompiler.define "FRENCH"}}source sources.lib} }

在上面的示例中，library 定義了“english”和“french”兩個(gè)flavor。當(dāng)編譯“french”變種時(shí)，會(huì)定義一個(gè)單獨(dú)的宏，以產(chǎn)生不同的二進(jìn)制文件。

如果一個(gè)組件沒(méi)有定義任何的flavor，那么會(huì)使用一個(gè)默認(rèn)的“default”的flavor。

54.8.4.?為一個(gè)組件選擇構(gòu)建類型，平臺(tái)和flavor

對(duì)于一個(gè)默認(rèn)的組件， Gradle會(huì)嘗試為這個(gè)project所定義的每一個(gè)buildType，?platform?和?flavor，以及它們的每一種組合，創(chuàng)建一個(gè)本地二進(jìn)制變種。通過(guò)指定的?targetBuildTypes，?targetPlatforms?或?targetFlavors，是可以在每一個(gè)組件的基礎(chǔ)上進(jìn)行重寫(xiě)的。

示例?54.24.?針對(duì)一個(gè)組件的特定平臺(tái)

build.gradle

executables {main {targetPlatforms "x86", "x64"} }

在這里你可以看到?TargetedNativeComponent.targetPlatforms()?方法被用于為?executables.main選擇一組平臺(tái)。

在選擇?TargetedNativeComponent.targetBuildTypes()?and和TargetedNativeComponent.targetFlavors()上也有類似的機(jī)制。

54.8.5.?構(gòu)建所有可能的變種

當(dāng)為一個(gè)組件定義了一組構(gòu)建類型，目標(biāo)平臺(tái)，以及flavor時(shí)，將會(huì)為它們的每一種可能的組合創(chuàng)建一個(gè)NativeBinary?模型元素。然而，在許多情況下是不可能構(gòu)建一個(gè)特定的變種的，可能的原因是某個(gè)特定的平臺(tái)沒(méi)有可用的工具鏈。

如果一個(gè)二進(jìn)制變種因?yàn)槟承┰虿荒軜?gòu)建，那么與之關(guān)聯(lián)的NativeBinary將不會(huì)是buildable。可以用這個(gè)屬性來(lái)創(chuàng)建一個(gè)任務(wù)，生成在某一特定計(jì)算機(jī)上所有可能的變種。

示例 54.25.?構(gòu)建所有可能的變種

build.gradle

task buildAllExecutables {dependsOn binaries.withType(ExecutableBinary).matching {it.buildable} }

54.9. 工具鏈

一個(gè)構(gòu)建可以使用不同的工具鏈來(lái)構(gòu)建不同平臺(tái)的變種。為此，核心的“native-binary”將嘗試查找并使支持的工具鏈可用。不過(guò)，一個(gè)項(xiàng)目里的一組工具鏈也可以被顯示地定義，允許配置額外的交叉編譯器以及指定安裝目錄。

54.9.1.?定義工具鏈

支持的工具鏈類型有︰

• Gcc

• Clang

• VisualCpp

示例 54.26.?定義工具鏈

build.gradle

model {toolChains {visualCpp(VisualCpp) {// Specify the installDir if Visual Studio cannot be located by default// installDir "C:/Apps/Microsoft Visual Studio 10.0"}gcc(Gcc) {// Uncomment to use a GCC install that is not in the PATH// path "/usr/bin/gcc"}clang(Clang)} }

每個(gè)工具鏈的實(shí)現(xiàn)都允許一定程度的配置（更多細(xì)節(jié)請(qǐng)參閱API文檔）

54.9.2. 使用工具鏈

指定構(gòu)建所使用的工具鏈?zhǔn)遣槐匾涂赡艿摹?duì)于給定的變種，Gradle 將嘗試查找能夠構(gòu)建目標(biāo)平臺(tái)的ToolChain。可用的工具鏈將按照定義的順序進(jìn)行查找。

當(dāng)一個(gè)平臺(tái)并沒(méi)有定義一個(gè)架構(gòu)或操作系統(tǒng)時(shí)，會(huì)被認(rèn)為使用默認(rèn)的工具鏈目標(biāo)。所以如果一個(gè)平臺(tái)沒(méi)有為operatingSystem定義一個(gè)值的話，Gradle 將會(huì)找到第一個(gè)可以用來(lái)構(gòu)建這個(gè)指定architecture的工具鏈。

核心 Gradle 工具鏈針對(duì)以下的架構(gòu)能夠開(kāi)箱即用。在每種情況中，工具鏈將針對(duì)當(dāng)前的操作系統(tǒng)。關(guān)于其他操作系統(tǒng)的交叉編譯的信息，可以參考下一節(jié)。

工具鏈	架構(gòu)
GCC	x86, x86_64
Clang	x86, x86_64
Visual C++	x86, x86_64, ia-64

所以對(duì)于linux上運(yùn)行的GCC，支持的目標(biāo)平臺(tái)是“l(fā)inux/x86”和“l(fā)inux/x86_64”。對(duì)于通過(guò)Cygwin運(yùn)行在Windows上的GCC，則支持“windows/x86”和“windows/x86_64”。（Cywgin運(yùn)行時(shí)還不能模擬為Platform的一部分，但以后將會(huì)實(shí)現(xiàn)。）

如果在project里沒(méi)有定義任何平臺(tái)，那么所有的二進(jìn)制文件會(huì)針對(duì)一個(gè)默認(rèn)平臺(tái)“current”進(jìn)行構(gòu)建。該默認(rèn)平臺(tái)不指定任何architecture或operatingSystem的值，因此會(huì)使用第一個(gè)可用的工具鏈的默認(rèn)值。

54.9.3.?使用GCC進(jìn)行交叉編譯

使用?Gcc?和?Clang?工具鏈，通過(guò) 以編程方式添加附加的目標(biāo)平臺(tái)的支持，是可以做到交叉編譯的。它通過(guò)?PlatformConfigurableToolChain?API來(lái)完成。每個(gè)添加的?TargetPlatformConfiguration?定義了對(duì)一個(gè)特定的目標(biāo)平臺(tái)的支持，并且提供了針對(duì)該平臺(tái)所需要的額外的工具參數(shù)。

54.10.?Visual Studio IDE 集成

Gradle 可以為在你的構(gòu)建中定義的本地組件生成生成 Visual Studio 項(xiàng)目及解決方案文件。這個(gè)功能是通過(guò)?visual-studio?插件添加的。對(duì)于多項(xiàng)目構(gòu)建，所有帶有本地組件的project都應(yīng)該應(yīng)用這個(gè)插件。

當(dāng)應(yīng)用?visual-studio?插件后，會(huì)為每一個(gè)定義的組件創(chuàng)建一個(gè)名為?${component.name}VisualStudio?的任務(wù)。這個(gè)任務(wù)會(huì)為所命名的組件生成一個(gè) Visual Studio Solution 文件。這個(gè)方案包含了一個(gè)該組件的 Visual Studio Project ，并且為每一個(gè)依賴的二進(jìn)制文件鏈接到項(xiàng)目文件中。

通過(guò)由visualStudio?提供的編程hook，可以修改所生成的visual studio文件的內(nèi)容， 更詳細(xì)的信息，可以參考“visual-studio”例子，或者參閱?VisualStudioExtension.getProjects()?及?VisualStudioExtension.getSolutions()?。

54.11.?CUnit 支持

Gradle?cunit?插件向你的native-binary項(xiàng)目提供了編譯及執(zhí)行CUnit 測(cè)試的支持。對(duì)于在你的項(xiàng)目中定義的每一個(gè)?Executable?和?Library，Gradle將創(chuàng)建一個(gè)匹配的?CUnitTestSuite?組件，名字為${component.name}Test。

54.11.1.?CUnit 源碼

Gradle將為項(xiàng)目中的每一個(gè)?CUnitTestSuite?組件創(chuàng)建一個(gè)名字為“cunit”的CSourceSet。這個(gè)源碼集應(yīng)包含組件源碼的 cunit 測(cè)試文件。源文件可以位于約定的位置（src/${component.name}Test/cunit），或者是像其他源集一樣配置到別的地方。

初始化 CUnit 測(cè)試注冊(cè)以及執(zhí)行這些測(cè)試的工作，都由 Gradle 通過(guò)一些生成的 CUnit 啟動(dòng)器源碼來(lái)執(zhí)行。Gradle 將認(rèn)定和調(diào)用一個(gè)void gradle_cunit_register()?函數(shù)，這個(gè)函數(shù)你可以用于配置實(shí)際的CUnit套件以及要執(zhí)行的測(cè)試。

示例 54.27. 注冊(cè) CUnit 測(cè)試

suite_operators.c

#include <CUnit/Basic.h> #include "gradle_cunit_register.h" #include "test_operators.h"int suite_init(void) {return 0; }int suite_clean(void) {return 0; }void gradle_cunit_register() {CU_pSuite pSuiteMath = CU_add_suite("operator tests", suite_init, suite_clean);CU_add_test(pSuiteMath, "test_plus", test_plus);CU_add_test(pSuiteMath, "test_minus", test_minus); } 由于這一機(jī)制，你的 CUnit 源碼可能不包含一個(gè)main方法，因?yàn)檫@會(huì)與 Gradle 所提供的方法產(chǎn)生沖突。

54.11.2.?構(gòu)建 CUnit 可執(zhí)行文件

一個(gè)?CUnitTestSuite?組件會(huì)有一個(gè)相關(guān)聯(lián)的?Executable?或?Library?組件。對(duì)于為main 組件配置的每一個(gè)ProjectNativeBinary，在測(cè)試套件組件上都會(huì)配置一個(gè)匹配的?TestSuiteExecutableBinary?。這些測(cè)試套件二進(jìn)制文件可以以一種類似的方式配置到任何其他二進(jìn)制的實(shí)例︰

示例 54.28. 注冊(cè) CUnit 測(cè)試

build.gradle

binaries.withType(TestSuiteExecutableBinary) {lib library: "cunit", linkage: "static"if (flavor == flavors.failing) {cCompiler.define "PLUS_BROKEN"} } 由你的項(xiàng)目和生成的啟動(dòng)器提供的兩種 CUnit 源碼，都需要核心 CUnit 頭文件和庫(kù)。目前，這個(gè)庫(kù)依賴項(xiàng)必須由你的項(xiàng)目為每個(gè)TestSuiteExecutableBinary提供。

54.11.3. 運(yùn)行 CUnit 測(cè)試

對(duì)于每個(gè)TestSuiteExecutableBinary，Gradle 將創(chuàng)建一個(gè)任務(wù)來(lái)執(zhí)行此二進(jìn)制文件，這項(xiàng)任務(wù)將運(yùn)行所有注冊(cè)的 CUnit 測(cè)試。生成的測(cè)試結(jié)果將位于${build.dir}/test-results目錄。

示例 54.29. 運(yùn)行 CUnit 測(cè)試

build.gradle

apply plugin: "c" apply plugin: "cunit"model {flavors {passingfailing}repositories {libs(PrebuiltLibraries) {cunit {headers.srcDir "lib/cunit/2.1-2/include"binaries.withType(StaticLibraryBinary) {staticLibraryFile = file("lib/cunit/2.1-2/lib/" + findCUnitLibForPlatform(targetPlatform))}}}} }libraries {operators {} } binaries.withType(TestSuiteExecutableBinary) {lib library: "cunit", linkage: "static"if (flavor == flavors.failing) {cCompiler.define "PLUS_BROKEN"} }

注意︰?此示例的代碼可以在Gradle 的 binary 或 source 分發(fā)包的samples/native-binaries/cunit中找到。。

> gradle -q runFailingOperatorsTestCUnitExeThere were test failures:1. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/cunit/test_plus.c:6 - plus(0, -2) == -22. /home/user/gradle/samples/native-binaries/cunit/src/operatorsTest/cunit/test_plus.c:7 - plus(2, 2) == 4:runFailingOperatorsTestCUnitExe FAILEDBUILD FAILEDTotal time: 1 secs

當(dāng)前對(duì) CUnit 的支持還是相當(dāng)簡(jiǎn)陋。未來(lái)的集成計(jì)劃包括：

• 允許測(cè)試聲明為 javadoc 風(fēng)格的注解。

• 改進(jìn) HTML 報(bào)告，類似于 JUnit 提供的那樣。

• 測(cè)試執(zhí)行的的實(shí)時(shí)反饋。

• 支持另外的測(cè)試框架。

總結(jié)

以上是生活随笔為你收集整理的Gradle 1.12用户指南翻译——第五十四章. 构建原生二进制文件的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。