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 plugin: 'java'
|
|
|
|
|
|
|
|
|
|
if (JavaVersion.current().isJava8Compatible()) {
|
|
|
|
|
tasks.withType(Javadoc) {
|
|
|
|
|
// disable the crazy super-strict doclint tool in Java 8
|
|
|
|
|
//noinspection SpellCheckingInspection
|
|
|
|
|
options.addStringOption('Xdoclint:none', '-quiet')
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
task jniHeaders {
|
|
|
|
|
def outputFolder = new File('../wpilibJavaJNI/build/include')
|
|
|
|
|
inputs.files sourceSets.main.output
|
|
|
|
|
outputs.file outputFolder
|
|
|
|
|
doLast {
|
|
|
|
|
outputFolder.mkdirs()
|
|
|
|
|
exec {
|
|
|
|
|
executable org.gradle.internal.jvm.Jvm.current().getExecutable('javah')
|
|
|
|
|
args '-d', outputFolder
|
|
|
|
|
args '-classpath', sourceSets.main.output.classesDir
|
|
|
|
|
args 'edu.wpi.first.wpilibj.can.CANJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.communication.FRCNetworkCommunicationsLibrary'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.HALUtil'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.JNIWrapper'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.AccelerometerJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.AnalogJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.CounterJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.DIOJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.EncoderJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.I2CJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.InterruptJNI'
|
This commit adds JNI bindings for the C++ Notifier.
The bindings only wrap the HAL interface, rather than the entire C++ Notifier,
as I ran into issues trying to wrap the whole Notifier (all the existing
bindings only wrap HAL components, so wrapping stuff in :wpilibc is
unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a
re-implementation of the wpilibc/.../Notifier.cpp.
The purpose of doing this bindings is to allow Java users a better option
for running tasks which require good timing (such as control loops). The
previous method used java.util.Timer to schedule a task, causing various
issues. Although this update does improve things, Java loop timing is still
substantially worse than that of C++, and, even worse, if Java decides to call
the garbage collector at the wrong time then the loop can be delayed by
multiple milliseconds and the next iteration will be shorter to account for it
(although this particular behavior could be updated).
A few notes on individual components:
-the HAL Task.hpp and Task.cpp were modified due to compilation/linkage
issues with the JNI bindings. Nothing substantive changed.
-NotifierJNI was added to the build files for gradle.
-HALUtil was modified to include a function for getting the length of a C
pointer, rather than relying on it being 32-bit.
Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
|
|
|
args 'edu.wpi.first.wpilibj.hal.NotifierJNI'
|
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 'edu.wpi.first.wpilibj.hal.PWMJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.RelayJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.SPIJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.SolenoidJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.CompressorJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.PDPJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.PowerJNI'
|
|
|
|
|
args 'edu.wpi.first.wpilibj.hal.SerialPortJNI'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
jniHeaders.dependsOn classes
|
|
|
|
|
|
|
|
|
|
sourceSets {
|
|
|
|
|
main {
|
|
|
|
|
java {
|
|
|
|
|
excludes = ['edu/wpi/first/wpilibj/camera/']
|
|
|
|
|
}
|
|
|
|
|
javadoc {
|
|
|
|
|
excludes = ['edu/wpi/first/wpilibj/camera/']
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
dependencies {
|
|
|
|
|
compile 'junit:junit:4.11'
|
|
|
|
|
compile project(':networktables:java')
|
|
|
|
|
compile project(':wpilibj:wpilibJava')
|
This commit adds JNI bindings for the C++ Notifier.
The bindings only wrap the HAL interface, rather than the entire C++ Notifier,
as I ran into issues trying to wrap the whole Notifier (all the existing
bindings only wrap HAL components, so wrapping stuff in :wpilibc is
unexplored). As such, the new edu.wpi.first.wpilibj.Notifier is just a
re-implementation of the wpilibc/.../Notifier.cpp.
The purpose of doing this bindings is to allow Java users a better option
for running tasks which require good timing (such as control loops). The
previous method used java.util.Timer to schedule a task, causing various
issues. Although this update does improve things, Java loop timing is still
substantially worse than that of C++, and, even worse, if Java decides to call
the garbage collector at the wrong time then the loop can be delayed by
multiple milliseconds and the next iteration will be shorter to account for it
(although this particular behavior could be updated).
A few notes on individual components:
-the HAL Task.hpp and Task.cpp were modified due to compilation/linkage
issues with the JNI bindings. Nothing substantive changed.
-NotifierJNI was added to the build files for gradle.
-HALUtil was modified to include a function for getting the length of a C
pointer, rather than relying on it being 32-bit.
Change-Id: I966512d8a82c2a438ed8c8bbcc6cdc6ed186d0f2
2015-06-02 14:00:47 -04:00
|
|
|
compile project(':hal')
|
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
|
|
|
}
|