Files
allwpilib/wpilibc/build.gradle

235 lines
8.1 KiB
Groovy
Raw Normal View History

apply plugin: 'cpp'
apply plugin: 'google-test'
apply plugin: 'visual-studio'
apply plugin: 'edu.wpi.first.NativeUtils'
Gradle Build This adds gradle support for building wpilibj and wpilibc. At this point, both of these libraries should be fully ready to go. Gradle should give us a number of improvements, including less dependencies for getting building up and running, and MUCH faster build times. I'm noticing significantly faster build times already compared to Maven, with neither system building the plugins. The changes here should be pretty straight forward. The basic command for gradle is './gradlew'. This is the gradle wrapper, and it will find and download the correct gradle executable for your system. There is no need to install anything yourself. To see every task available, run './gradlew tasks'. The important tasks for us are listed under the WPILib header when the tasks command is run. To generate unit test binaries, the fRCUserProgramExecutable command will create the C++ tester, and the wpilibjIntegrationTestJar command will create the Java tester. The Jenkins deploy scripts have been modified to know the difference between maven generated and gradle generated jars with an environment variable. Creating the eclipse plugins still requires Maven, but gradle will handle calling it correctly and generating the proper dependencies for it. Create the plugins by calling ./gradlew eclipsePlugins. Jenkins can now be modified to support the new build system. Unit tests are run with ./gradlew test. Generating the integration tests uses the above two commands, and then process proceeds exactly as it did before. For publishing documentation, a new task has been created, ./gradlew publishDocs, which handles putting the documentation where Jenkins expects for publishing. Change-Id: I9a260d391984f98ef9170993efe933e4026161dc
2015-05-05 09:54:14 -04:00
apply from: '../config.gradle'
Gradle Build This adds gradle support for building wpilibj and wpilibc. At this point, both of these libraries should be fully ready to go. Gradle should give us a number of improvements, including less dependencies for getting building up and running, and MUCH faster build times. I'm noticing significantly faster build times already compared to Maven, with neither system building the plugins. The changes here should be pretty straight forward. The basic command for gradle is './gradlew'. This is the gradle wrapper, and it will find and download the correct gradle executable for your system. There is no need to install anything yourself. To see every task available, run './gradlew tasks'. The important tasks for us are listed under the WPILib header when the tasks command is run. To generate unit test binaries, the fRCUserProgramExecutable command will create the C++ tester, and the wpilibjIntegrationTestJar command will create the Java tester. The Jenkins deploy scripts have been modified to know the difference between maven generated and gradle generated jars with an environment variable. Creating the eclipse plugins still requires Maven, but gradle will handle calling it correctly and generating the proper dependencies for it. Create the plugins by calling ./gradlew eclipsePlugins. Jenkins can now be modified to support the new build system. Unit tests are run with ./gradlew test. Generating the integration tests uses the above two commands, and then process proceeds exactly as it did before. For publishing documentation, a new task has been created, ./gradlew publishDocs, which handles putting the documentation where Jenkins expects for publishing. Change-Id: I9a260d391984f98ef9170993efe933e4026161dc
2015-05-05 09:54:14 -04:00
ext.addWpilibCCompilerArguments = { binary->
tasks.withType(CppCompile) {
binary.cppCompiler.args "-DNAMESPACED_WPILib"
}
}
ext.addWpilibCToLinker = { binary->
binary.lib project: ':wpilibc', library: 'wpilibc', linkage: 'shared'
}
Gradle Build This adds gradle support for building wpilibj and wpilibc. At this point, both of these libraries should be fully ready to go. Gradle should give us a number of improvements, including less dependencies for getting building up and running, and MUCH faster build times. I'm noticing significantly faster build times already compared to Maven, with neither system building the plugins. The changes here should be pretty straight forward. The basic command for gradle is './gradlew'. This is the gradle wrapper, and it will find and download the correct gradle executable for your system. There is no need to install anything yourself. To see every task available, run './gradlew tasks'. The important tasks for us are listed under the WPILib header when the tasks command is run. To generate unit test binaries, the fRCUserProgramExecutable command will create the C++ tester, and the wpilibjIntegrationTestJar command will create the Java tester. The Jenkins deploy scripts have been modified to know the difference between maven generated and gradle generated jars with an environment variable. Creating the eclipse plugins still requires Maven, but gradle will handle calling it correctly and generating the proper dependencies for it. Create the plugins by calling ./gradlew eclipsePlugins. Jenkins can now be modified to support the new build system. Unit tests are run with ./gradlew test. Generating the integration tests uses the above two commands, and then process proceeds exactly as it did before. For publishing documentation, a new task has been created, ./gradlew publishDocs, which handles putting the documentation where Jenkins expects for publishing. Change-Id: I9a260d391984f98ef9170993efe933e4026161dc
2015-05-05 09:54:14 -04:00
def versionClass = """
/*
* Autogenerated file! Do not manually edit this file. This version is regenerated
* any time the publish task is run, or when this file is deleted.
*/
const char* GetWPILibVersion() {
return "${WPILibVersion.version}";
}
""".trim()
def wpilibVersionFile = file('src/main/native/cpp/WPILibVersion.cpp')
def willPublish = false
gradle.taskGraph.addTaskExecutionGraphListener { graph ->
willPublish = graph.hasTask(publish)
}
task generateCppVersion() {
description = 'Generates the wpilib version class'
group = 'WPILib'
// We follow a simple set of checks to determine whether we should generate a new version file:
// 1. If the release type is not development, we generate a new verison file
// 2. If there is no generated version number, we generate a new version file
// 3. If there is a generated build number, and the release type is development, then we will
// only generate if the publish task is run.
doLast {
if (!WPILibVersion.releaseType.toString().equalsIgnoreCase('official') && !willPublish && wpilibVersionFile.exists()) {
return
}
println "Writing version ${WPILibVersion.version} to $wpilibVersionFile"
if (wpilibVersionFile.exists()) {
wpilibVersionFile.delete()
}
wpilibVersionFile.write(versionClass)
}
}
clean {
delete wpilibVersionFile
}
model {
dependencyConfigs {
wpiutil(DependencyConfig) {
groupId = 'edu.wpi.first.wpiutil'
artifactId = 'wpiutil-cpp'
headerClassifier = 'headers'
ext = 'zip'
version = '3.+'
sharedConfigs = [ wpilibc: [],
2017-08-21 15:15:38 -07:00
wpilibcTestingBaseTest: [],
wpilibcDev: [] ]
}
ntcore(DependencyConfig) {
groupId = 'edu.wpi.first.ntcore'
artifactId = 'ntcore-cpp'
headerClassifier = 'headers'
ext = 'zip'
version = '4.+'
sharedConfigs = [ wpilibc: [],
2017-08-21 15:15:38 -07:00
wpilibcTestingBaseTest: [],
wpilibcDev: [] ]
}
opencv(DependencyConfig) {
groupId = 'org.opencv'
artifactId = 'opencv-cpp'
headerClassifier = 'headers'
ext = 'zip'
version = '3.2.0'
sharedConfigs = [ wpilibc: [],
2017-08-21 15:15:38 -07:00
wpilibcTestingBaseTest: [],
wpilibcDev: [] ]
}
cscore(DependencyConfig) {
groupId = 'edu.wpi.first.cscore'
artifactId = 'cscore-cpp'
headerClassifier = 'headers'
ext = 'zip'
version = '1.+'
sharedConfigs = [ wpilibc: [],
2017-08-21 15:15:38 -07:00
wpilibcTestingBaseTest: [],
wpilibcDev: [] ]
}
}
exportsConfigs {
wpilibc(ExportsConfig) {
x86ExcludeSymbols = [ '_CT??_R0?AV_System_error', '_CT??_R0?AVexception', '_CT??_R0?AVfailure',
'_CT??_R0?AVbad_cast',
'_CT??_R0?AVruntime_error', '_CT??_R0?AVsystem_error', '_CTA5?AVfailure',
'_TI5?AVfailure' ]
x64ExcludeSymbols = [ '_CT??_R0?AV_System_error', '_CT??_R0?AVexception', '_CT??_R0?AVfailure',
'_CT??_R0?AVbad_cast',
'_CT??_R0?AVruntime_error', '_CT??_R0?AVsystem_error', '_CTA5?AVfailure',
'_TI5?AVfailure' ]
}
}
components {
wpilibc(NativeLibrarySpec) {
sources {
cpp {
source {
srcDirs = [ 'src/main/native/cpp' ]
includes = ["**/*.cpp"]
}
exportedHeaders {
srcDirs = ["src/main/native/include"]
}
}
}
}
// The TestingBase library is a workaround for an issue with the GoogleTest plugin.
// The plugin by default will rebuild the entire test source set, which increases
// build time. By testing an empty library, and then just linking the already built component
// into the test, we save the extra build
if (!project.hasProperty('onlyAthena')) {
wpilibcTestingBase(NativeLibrarySpec) { }
}
// By default, a development executable will be generated. This is to help the case of
// testing specific functionality of the library.
if (!project.hasProperty('skipDevExe')) {
wpilibcDev(NativeExecutableSpec) {
binaries.all {
project.addWpilibCToLinker(it)
}
sources {
cpp {
source {
srcDirs 'src/dev/native/cpp'
include '**/*.cpp'
}
exportedHeaders {
srcDirs 'src/dev/native/include'
}
}
}
}
}
}
testSuites {
if (!project.hasProperty('onlyAthena')) {
wpilibcTestingBaseTest {
sources {
cpp.source.srcDir 'src/test/native/cpp'
cpp.exportedHeaders.srcDir 'src/test/native/include'
}
}
}
}
binaries {
all {
tasks.withType(CppCompile) {
dependsOn generateCppVersion
}
project(':hal').addHalCompilerArguments(it)
project(':ni-libraries').addNiLibrariesToLinker(it)
project(':hal').addHalToLinker(it)
project.addWpilibCCompilerArguments(it)
}
withType(GoogleTestTestSuiteBinarySpec) {
if (it.component.testedComponent.name.contains('TestingBase') && !project.hasProperty('onlyAthena')) {
project(':gmock').addGmockToLinker(it)
project.addWpilibCToLinker(it)
} else {
it.buildable = false
}
}
}
tasks {
runCpp(Exec) {
def found = false
$.components.each {
if (it in NativeExecutableSpec && it.name == 'wpilibcDev') {
it.binaries.each {
if (!found) {
def arch = it.targetPlatform.architecture.name
if (arch == 'x86-64' || arch == 'x86') {
dependsOn it.tasks.install
commandLine it.tasks.install.runScript
found = true
}
}
}
}
}
}
getHeaders(Task) {
def list = []
$.components.each {
if (it in NativeLibrarySpec && it.name == 'wpilibc') {
it.sources.each {
it.exportedHeaders.srcDirs.each {
list.add(it)
}
}
it.binaries.each {
it.libs.each {
it.includeRoots.each {
list.add(it)
}
}
}
}
}
list = list.unique(false)
doLast {
list.each {
print "WPIHEADER: "
println it
}
}
}
Gradle Build This adds gradle support for building wpilibj and wpilibc. At this point, both of these libraries should be fully ready to go. Gradle should give us a number of improvements, including less dependencies for getting building up and running, and MUCH faster build times. I'm noticing significantly faster build times already compared to Maven, with neither system building the plugins. The changes here should be pretty straight forward. The basic command for gradle is './gradlew'. This is the gradle wrapper, and it will find and download the correct gradle executable for your system. There is no need to install anything yourself. To see every task available, run './gradlew tasks'. The important tasks for us are listed under the WPILib header when the tasks command is run. To generate unit test binaries, the fRCUserProgramExecutable command will create the C++ tester, and the wpilibjIntegrationTestJar command will create the Java tester. The Jenkins deploy scripts have been modified to know the difference between maven generated and gradle generated jars with an environment variable. Creating the eclipse plugins still requires Maven, but gradle will handle calling it correctly and generating the proper dependencies for it. Create the plugins by calling ./gradlew eclipsePlugins. Jenkins can now be modified to support the new build system. Unit tests are run with ./gradlew test. Generating the integration tests uses the above two commands, and then process proceeds exactly as it did before. For publishing documentation, a new task has been created, ./gradlew publishDocs, which handles putting the documentation where Jenkins expects for publishing. Change-Id: I9a260d391984f98ef9170993efe933e4026161dc
2015-05-05 09:54:14 -04:00
}
}
apply from: 'publish.gradle'