Files
allwpilib/build.gradle

226 lines
10 KiB
Groovy
Raw Normal View History

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
import org.apache.tools.ant.taskdefs.condition.Os
// This regex matches either a Windows or Unix style file separator, then the lib part of the library,
// then the name of the library itself, and finally the .so extension at the end. The name of the library
// is in the libName capture group, which is extracted and used for the linker flags
def libPattern = /.*((\\/|\\).*)+lib(?<libName>.+).so$/
def niLibraryArgs = []
def wpiLibraryArgs = []
def niLibraryPath = file('ni-libraries').path
// The NI Library tree includes all non-wpi libraries, which is everything that doesn't have libwpi in the name
def niLibraryTree = fileTree(niLibraryPath)
niLibraryTree.include '*.so'
niLibraryTree.exclude '*libwpi*.so'
// This adds all linker flags to the list of ni library linker flags
niLibraryTree.each { lib ->
def nameMatcher = (lib.path =~ libPattern)
if (nameMatcher[0].size() > 1) {
def name = nameMatcher.group('libName')
niLibraryArgs << '-l' + name
}
}
// The WPI libraries are libraries in the ni-libraries folder that have libwpi in their names
def wpiLibraryTree = fileTree(niLibraryPath)
wpiLibraryTree.include '*libwpi*.so'
// This adds all linker flags to the list of wpi library linker flags
wpiLibraryTree.each { lib ->
def nameMatcher = (lib.path =~ libPattern)
if (nameMatcher[0].size() > 1) {
def name = nameMatcher[0][1]
wpiLibraryArgs << '-l' + name
}
}
// Shells out to maven for generates the eclipse plugins.
// TODO: Get gradle to build this natively, rather than relying on maven. A plugin exists to do this, called Wuff, but this needs more investigation
// https://github.com/akhikhl/wuff
task eclipsePlugins(type: Exec) {
description = 'Executes the maven build of the eclipse plugins'
group = 'WPILib'
workingDir 'eclipse-plugins'
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
executable 'mvn.cmd'
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
} else {
executable 'mvn'
}
args 'package'
}
// Rather than a normal clean, which executes whenever the clean task is run, this must be manually invoked. This
// is because the maven processes is very verbose and takes a long time, checking all of the eclipse repositories
task cleanEclipsePlugins(type: Exec) {
description = 'Cleans the maven build of the eclipse plugins'
group = 'WPILib'
workingDir 'eclipse-plugins'
if (Os.isFamily(Os.FAMILY_WINDOWS)) {
executable 'mvn.cmd'
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
} else {
executable 'mvn'
}
args 'clean'
}
subprojects {
apply plugin: 'eclipse'
apply plugin: 'idea'
repositories {
mavenCentral()
mavenLocal()
}
// Disables doclint in java 8.
if (JavaVersion.current().isJava8Compatible()) {
allprojects {
tasks.withType(Javadoc) {
options.addStringOption('Xdoclint:none', '-quiet')
}
}
}
// Make sure that all maven publishing routines are run before the maven process starts
plugins.withType(MavenPublishPlugin).whenPluginAdded {
eclipsePlugins.dependsOn publishToMavenLocal
}
plugins.withType(CppPlugin).whenPluginAdded {
model {
buildTypes {
debug
}
// Adds a custom toolchain for our compiler prefix and options
toolChains {
gcc(Gcc) {
target('arm') {
// We use a custom-built cross compiler with the prefix arm-frc-linux-gnueabi-<util name>
// If this ever changes, the prefix will need to be changed here
def compilerPrefix = 'arm-frc-linux-gnueabi-'
cppCompiler.executable = compilerPrefix + cppCompiler.executable
linker.executable = compilerPrefix + linker.executable
assembler.executable = compilerPrefix + assembler.executable
// Gradle auto-adds the -m32 argument to the linker and compiler. Our compiler only supports
// arm, and doesn't understand this flag, so it is removed from both
cppCompiler.withArguments { args ->
args << '-std=c++1y' << '-Wformat=2' << '-Wall' << '-Wextra' << '-Werror' << '-pedantic'
args << '-Wno-psabi' << '-Wno-unused-parameter' << '-fPIC' << '-O0' << '-g3' << '-rdynamic'
artf4154: Get rid of raw pointers in C++. This deals with the majority of the user-facing code in wpilibC++Devices and a substantial portion of it in wpilibC++. wpilibC++Sim and wpilibC++IntegrationTests are untouched except where it is necessary to make them work with the rest of the libraries. There is still a lot to do in the following areas: -The HAL (which we may not want to touch at all). -The I2C, Serial, and SPI interfaces in wpilibC++Devices, which I haven't gotten around to doing yet. -Most wpilibC++Devices classes have void* pointers for interacting with the HAL. -InterruptableSensorBase passes a void *params for the interrupt handler. -I haven't converted all the const char* to std::strings. -There are plenty of other cases of raw pointers still existing. -This doesn't fall directly under raw pointer stuff, but move syntax and rvalue references could be introduced in many places. -I haven't touched vision code. -The Resource classes conflict (one is in the hal, the other in wpilibC++). Someone should figure out a more permanent fix (eg, just renaming them), then doing what I did (making a new namespace for one of them, essentially the same as renaming it). A few other things: -I created a NullDeleter class which is marked as deprecated. What this does is it can be passed as the deleter to a std::shared_ptr so that when you are converting raw pointers to shared_ptrs the shared_ptr doesn't do any deletion if someone else owns the raw pointer. This should only be used in making old raw pointer UIs. -I had to alter the build.gradle so that it did not emit errors when deprecated functions called deprecated functions. Unfortunately, gradle doesn't appear to be actually printing out gcc warnigns for some reason. The best way I have found to fix this is to patch the toolchains (https://bitbucket.org/byteit101/toolchain-builder/pull-request/5/make-gcc-not-throw-warnings-for-nested/diff) so that a deprecated function calling a deprecated function is fine but a non-deprecated function calling a deprecated function will throw a warning (which we then elevate with -Werror). I believe that clang deals with this properly, although I have not tried it myself. Change-Id: Ib8090c66893576fe73654f4e9d268f9d37be06a2
2015-06-30 15:01:20 -04:00
//TODO: When the compiler allows us to actually call deprecated functions from within
// deprecated function, remove this line (this will cause calling deprecated functions
// to be treated as a warning rather than an error).
args << '-Wno-error=deprecated-declarations'
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
args.remove('-m32')
}
linker.withArguments { args ->
args << '-rdynamic'
args.remove('-m32')
}
staticLibArchiver.executable = compilerPrefix + staticLibArchiver.executable
}
}
// Workaround for OS X. Macs for some reason want to use Xcode's gcc
// (which just wraps Clang), so we have to explicitly make it so
// that trying to compile with Clang will call gcc instead
macGcc(Clang) {
target('arm') {
// We use a custom-built cross compiler with the prefix arm-frc-linux-gnueabi-<util name>
// If this ever changes, the prefix will need to be changed here
def compilerPrefix = 'arm-frc-linux-gnueabi-'
cppCompiler.executable = compilerPrefix + 'g++'
linker.executable = compilerPrefix + 'g++'
assembler.executable = compilerPrefix + 'gcc'
// Gradle auto-adds the -m32 argument to the linker and compiler. Our compiler only supports
// arm, and doesn't understand this flag, so it is removed from both
cppCompiler.withArguments { args ->
args << '-std=c++1y' << '-Wformat=2' << '-Wall' << '-Wextra' << '-Werror' << '-pedantic'
args << '-Wno-psabi' << '-Wno-unused-parameter' << '-fPIC' << '-O0' << '-g3' << '-rdynamic'
//TODO: When the compiler allows us to actually call deprecated functions from within
// deprecated function, remove this line (this will cause calling deprecated functions
// to be treated as a warning rather than an error).
args << '-Wno-error=deprecated-declarations'
args.remove('-m32')
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
}
linker.withArguments { args ->
args << '-rdynamic'
args.remove('-m32')
}
staticLibArchiver.executable = compilerPrefix + 'ar'
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
}
}
}
// The only platform is arm linux
platforms {
arm {
architecture 'arm'
operatingSystem 'linux'
}
}
}
// This task adds the appropriate linker flags for the NI libraries
task addNiLibraryLinks() {
description = 'Adds the linker flags for the NI libraries in the ni-library folders'
group = 'WPILib'
doLast {
binaries.all {
tasks.withType(CppCompile) {
// desktop version doesn't use all the NI libraries
// so only do this for arm libraries
String architecture = targetPlatform.architecture
if (architecture.contains('arm')){
linker.args << '-L' + niLibraryPath
linker.args.addAll(niLibraryArgs)
}
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
}
}
model {
repositories {
libs(PrebuiltLibraries) { libs ->
// Loops through all .so files (except files matching *libwpi*.so) in ../ni-libraries
// and includes them for linking
niLibraryTree.each { niLib ->
libs.create(niLib) {
binaries.withType(SharedLibraryBinary) {
sharedLibraryFile = file(niLib.path)
}
}
}
}
}
}
}
}
// This task adds the appropriate linker flags for the WPI libraries
task addWpiLibraryLinks() {
description = 'Adds the linker flags for the WPI libraries in the ni-library folders'
group = 'WPILib'
doLast {
binaries.all {
linker.args.addAll(wpiLibraryArgs)
}
model {
repositories {
libs(PrebuiltLibraries) { libs ->
// Loops through all libwpi*.so files in ../ni-libraries and includes them for linking
wpiLibraryTree.each { niLib ->
libs.create(niLib) {
binaries.withType(SharedLibraryBinary) {
sharedLibraryFile = file(niLib.path)
}
}
}
}
}
}
}
}
// Whenever we add the WPI library links, we'll also need the ni libraries, so set up that dependency
addWpiLibraryLinks.dependsOn addNiLibraryLinks
}
}