第五十四章. 構建原生二進制文件

對于每個產生的可執行二進制文件，?cpp插件提供了install${binary.name}任務，這個任務可以創建該可執行文件及它需要的共享庫的開發安裝。它允許你運行可執行文件，而無需在其最終的位置安裝共享庫。

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

apply plugin: 'cpp'

把 C++ 源碼包含到原生二進制文件中，是通過一個?CppSourceSet來實現的，它定義了一個C++源文件集以及（可選的）一個可導出的頭文件（用于library）集默認情況下，對于任何命名的組件，CppSourceSet包含了在src/${name}/cpp中的.cpp源文件，和在src/${name}/headers中的頭文件。

而cpp插件為每個CppSourceSet定義了這些默認的位置，且可以擴展或重寫這些默認值使能夠成為不同的項目布局。

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

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

'c'?插件提供了C 語言的支持。

apply plugin: 'c'

把 C 源碼包含到原生二進制文件中，是通過一個?CSourceSet來實現的，它定義了一個C源文件集以及（可選的）一個可導出的頭文件（用于library）集默認情況下，對于任何命名的組件，CSourceSet包含了在src/${name}/c中的.c源文件，和在src/${name}/headers中的頭文件。

而c插件為每個CSourceSet定義了這些默認的位置，且可以擴展或重寫這些默認值使能夠成為不同的項目布局。

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

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

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

apply plugin: 'assembler'

把匯編源碼包含到原生二進制文件中，是通過一個?AssemblerSourceSet來實現的，它定義了一個匯編源文件集。默認情況下，對于任何命名的組件，AssemblerSourceSet包含了在src/${name}/asm中的.s源文件。

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

apply plugin: 'objective-c'

把Objective-C源碼包含到原生二進制文件中，是通過一個?ObjectiveCSourceSet來實現的，它定義了一個Objective-C源文件集。默認情況下，對于任何命名的組件，ObjectiveCSourceSet包含了在src/${name}/objectiveC中的.m源文件。

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

apply plugin: 'objective-cpp'

把Objective-C++源碼包含到原生二進制文件中，是通過一個?ObjectiveCppSourceSet來實現的，它定義了一個Objective-C++源文件集。默認情況下，對于任何命名的組件，ObjectiveCppSourceSet包含了在src/${name}/objectiveCpp中的.mm源文件。

一組源文件可能依賴于在同一個項目中由另一個二進制組件提供的頭文件。一個常見的例子是一個本地可執行組件，使用了由一個單獨的本地庫組件提供的功能。

這樣的庫依賴可以很方便地提供給source set關聯上executable組件。

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

另外，一個庫依賴項可以直接提供給ExecutableBinary的executable。

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

對于在不同的 Gradle 項目產生的組件，notation是類似的。

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

一個?build type?確定了一個二進制文件的各種非功能性方面，比如是否包含調試信息，或者使用什么樣的優化級別來編譯二進制文件。典型的構建類型是“debug”和“release”，但一個project可以自由定義任意的構建類型。

model {buildTypes {debugrelease}
}

如果在project中沒有定義任何構建類型，那么會有一個默認的“debug”構建類型被加進去。

對于一個構建類型，Gradle project 通常會定義一組每個工具鏈的編譯器/鏈接器標志。

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'}
}

通過為每個平臺生成一個變種，能夠使一個可執行文件或庫構建為可以運行在不同的操作系統及CPU架構上。Gradle 把每一個系統架構組合定義為一個?Platform，一個project可以定義多個platforms。如果在project里沒有定義任何平臺，那么會添加一個默認的“current”平臺。

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

對于給定的變種，Gradle 將嘗試查找能夠構建目標平臺的ToolChain。可用的工具鏈將按照定義的順序進行查找。更多的細節請參閱下面的工具鏈部分。

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

一個關于組件flavor的例子是可以區分組件的“demo”，“paid”和“enterprise”版本，它們都用同樣的源碼來生成不同功能的二進制文件。

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

在上面的示例中，library 定義了“english”和“french”兩個flavor。當編譯“french”變種時，會定義一個單獨的宏，以產生不同的二進制文件。

如果一個組件沒有定義任何的flavor，那么會使用一個默認的“default”的flavor。

對于一個默認的組件， Gradle會嘗試為這個project所定義的每一個buildType，?platform?和?flavor，以及它們的每一種組合，創建一個本地二進制變種。通過指定的?targetBuildTypes，?targetPlatforms?或?targetFlavors，是可以在每一個組件的基礎上進行重寫的。

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

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

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

當為一個組件定義了一組構建類型，目標平臺，以及flavor時，將會為它們的每一種可能的組合創建一個NativeBinary?模型元素。然而，在許多情況下是不可能構建一個特定的變種的，可能的原因是某個特定的平臺沒有可用的工具鏈。

如果一個二進制變種因為某些原因不能構建，那么與之關聯的NativeBinary將不會是buildable。可以用這個屬性來創建一個任務，生成在某一特定計算機上所有可能的變種。

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

支持的工具鏈類型有︰

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

每個工具鏈的實現都允許一定程度的配置（更多細節請參閱API文檔）

指定構建所使用的工具鏈是不必要和可能的。對于給定的變種，Gradle 將嘗試查找能夠構建目標平臺的ToolChain。可用的工具鏈將按照定義的順序進行查找。

核心 Gradle 工具鏈針對以下的架構能夠開箱即用。在每種情況中，工具鏈將針對當前的操作系統。關于其他操作系統的交叉編譯的信息，可以參考下一節。

所以對于linux上運行的GCC，支持的目標平臺是“linux/x86”和“linux/x86_64”。對于通過Cygwin運行在Windows上的GCC，則支持“windows/x86”和“windows/x86_64”。（Cywgin運行時還不能模擬為Platform的一部分，但以后將會實現。）

如果在project里沒有定義任何平臺，那么所有的二進制文件會針對一個默認平臺“current”進行構建。該默認平臺不指定任何architecture或operatingSystem的值，因此會使用第一個可用的工具鏈的默認值。

使用?Gcc?和?Clang?工具鏈，通過 以編程方式添加附加的目標平臺的支持，是可以做到交叉編譯的。它通過?PlatformConfigurableToolChain?API來完成。每個添加的?TargetPlatformConfiguration?定義了對一個特定的目標平臺的支持，并且提供了針對該平臺所需要的額外的工具參數。

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

初始化 CUnit 測試注冊以及執行這些測試的工作，都由 Gradle 通過一些生成的 CUnit 啟動器源碼來執行。Gradle 將認定和調用一個void gradle_cunit_register()?函數，這個函數你可以用于配置實際的CUnit套件以及要執行的測試。

#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);
}

一個?CUnitTestSuite?組件會有一個相關聯的?Executable?或?Library?組件。對于為main 組件配置的每一個ProjectNativeBinary，在測試套件組件上都會配置一個匹配的?TestSuiteExecutableBinary?。這些測試套件二進制文件可以以一種類似的方式配置到任何其他二進制的實例︰

binaries.withType(TestSuiteExecutableBinary) {lib library: "cunit", linkage: "static"if (flavor == flavors.failing) {cCompiler.define "PLUS_BROKEN"}
}

對于每個TestSuiteExecutableBinary，Gradle 將創建一個任務來執行此二進制文件，這項任務將運行所有注冊的 CUnit 測試。生成的測試結果將位于${build.dir}/test-results目錄。

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