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: 'cpp'
|
|
|
|
|
apply plugin: 'maven-publish'
|
|
|
|
|
apply plugin : 'org.ysb33r.doxygen'
|
|
|
|
|
|
|
|
|
|
buildscript {
|
|
|
|
|
repositories {
|
|
|
|
|
jcenter()
|
|
|
|
|
}
|
|
|
|
|
dependencies {
|
|
|
|
|
classpath 'org.ysb33r.gradle:doxygen:0.2'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
def shared = 'wpilibC++'
|
|
|
|
|
def devices = 'wpilibC++Devices'
|
|
|
|
|
def sim = 'wpilibC++Sim'
|
|
|
|
|
|
|
|
|
|
// Ensure that both hal and networktables are evaluated, so that they have the binaries property. We need this to
|
|
|
|
|
// properly copy their archives into the final zip
|
|
|
|
|
evaluationDependsOn(':hal')
|
2015-08-13 23:17:19 -07:00
|
|
|
evaluationDependsOn(':networktables:ntcore')
|
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
|
|
|
|
|
|
|
|
publishing {
|
|
|
|
|
publications {
|
|
|
|
|
maven(MavenPublication) {
|
|
|
|
|
artifact wpilibcZip
|
|
|
|
|
groupId 'edu.wpi.first.wpilib.cmake'
|
|
|
|
|
artifactId 'cpp-root'
|
|
|
|
|
version '1.0.0'
|
|
|
|
|
}
|
|
|
|
|
mavenSim(MavenPublication) {
|
|
|
|
|
artifact wpilibcSimZip
|
|
|
|
|
groupId 'edu.wpi.first.wpilibc.simulation'
|
|
|
|
|
artifactId 'WPILibCSim'
|
|
|
|
|
version '0.1.0'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
model {
|
|
|
|
|
components {
|
|
|
|
|
wpilib_nonshared(NativeLibrarySpec) {
|
|
|
|
|
targetPlatform 'arm'
|
|
|
|
|
binaries.all {
|
|
|
|
|
tasks.withType(CppCompile) {
|
|
|
|
|
dependsOn addNiLibraryLinks
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
sources {
|
|
|
|
|
cpp {
|
|
|
|
|
source {
|
|
|
|
|
srcDirs = ["${shared}/src", "${devices}/src"]
|
|
|
|
|
includes = ['**/*.cpp']
|
|
|
|
|
}
|
|
|
|
|
exportedHeaders {
|
|
|
|
|
srcDirs = ["${shared}/include", "${devices}/include"]
|
|
|
|
|
includes = ['**/*.h']
|
|
|
|
|
}
|
|
|
|
|
lib project: ':hal', library: 'HALAthena', linkage: 'static'
|
2015-08-13 23:17:19 -07:00
|
|
|
lib project: ':networktables:ntcore', library: 'ntcore', linkage: 'static'
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
FRCUserProgram(NativeExecutableSpec) {
|
|
|
|
|
targetPlatform 'arm'
|
|
|
|
|
binaries.all {
|
|
|
|
|
tasks.withType(CppCompile) {
|
|
|
|
|
dependsOn addNiLibraryLinks
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
cppCompiler.args '-pthread'
|
|
|
|
|
linker.args '-pthread'
|
|
|
|
|
cppCompiler.args '-Wno-unused-variable'
|
|
|
|
|
linker.args '-Wno-unused-variable'
|
2015-09-27 14:09:17 -04:00
|
|
|
linker.args '-Wl,-rpath,/opt/GenICam_v2_3/bin/Linux_armv7-a,-rpath,/usr/local/frc/rpath-lib'
|
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
|
|
|
}
|
|
|
|
|
sources {
|
|
|
|
|
cpp {
|
|
|
|
|
def dir = 'wpilibC++IntegrationTests'
|
|
|
|
|
source {
|
2015-07-30 10:00:53 -04:00
|
|
|
srcDirs = ["${dir}/src", "${dir}/src/command"]
|
|
|
|
|
includes = ['*.cpp']
|
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
|
|
|
}
|
|
|
|
|
source {
|
|
|
|
|
srcDir "${dir}/src/gtest/src"
|
|
|
|
|
include 'gtest-all.cc', 'gtest_main.cc'
|
|
|
|
|
}
|
|
|
|
|
exportedHeaders {
|
2015-08-13 23:17:19 -07:00
|
|
|
srcDirs = ["${dir}/include", "${dir}/src/gtest", "${dir}/src/gtest/include", "${devices}/include", "${shared}/include", '../hal/include/HAL', '../networktables/ntcore/include']
|
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
|
|
|
include '**/*.h'
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lib library: 'wpilib_nonshared', linkage: 'static'
|
2015-08-13 23:17:19 -07:00
|
|
|
lib project: ':networktables:ntcore', library: 'ntcore', linkage: 'static'
|
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
|
|
|
lib project: ':hal', library: 'HALAthena', linkage: 'static'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
doxygen {
|
|
|
|
|
source file("${shared}/src")
|
|
|
|
|
source file("${shared}/include")
|
|
|
|
|
source file("${devices}/src")
|
|
|
|
|
source file("${devices}/include")
|
2015-08-13 23:17:19 -07:00
|
|
|
def netTablesLoc = '../networktables/ntcore'
|
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
|
|
|
source file("${netTablesLoc}/include")
|
|
|
|
|
source file("${netTablesLoc}/lib/Athena")
|
|
|
|
|
source file("${netTablesLoc}/lib/share")
|
|
|
|
|
template file('cpp.doxy')
|
|
|
|
|
exclude 'pcre.h'
|
|
|
|
|
exclude 'nivision.h'
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
task wpilibcZip(type: Zip) {
|
|
|
|
|
description = 'Zips all of the libraries for wpilibc'
|
|
|
|
|
group = 'WPILib'
|
|
|
|
|
baseName = 'wpilibc'
|
|
|
|
|
destinationDir = project.buildDir
|
|
|
|
|
|
|
|
|
|
// If doxygen is available on this computer, then include the output zip
|
|
|
|
|
if (checkDoxygen()) {
|
|
|
|
|
from(doxygen.outputDir) {
|
|
|
|
|
into 'docs'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Include the static library file and header files from this project
|
|
|
|
|
binaries.withType(StaticLibraryBinarySpec) { spec ->
|
|
|
|
|
spec.headerDirs.each {
|
|
|
|
|
from(it) {
|
|
|
|
|
into 'include'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
from(spec.staticLibraryFile) {
|
2015-06-10 10:40:49 -04:00
|
|
|
into 'lib'
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Include the static library file and header files from the networktables project
|
2015-08-13 23:17:19 -07:00
|
|
|
def netTables = project(':networktables:ntcore')
|
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
|
|
|
netTables.binaries.withType(StaticLibraryBinarySpec) { spec ->
|
|
|
|
|
spec.headerDirs.each {
|
|
|
|
|
from(it) {
|
|
|
|
|
into 'include'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
from(spec.staticLibraryFile) {
|
2015-06-10 10:40:49 -04:00
|
|
|
into 'lib'
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Include the static library file and shared library object from hal project
|
|
|
|
|
def hal = project(':hal')
|
|
|
|
|
hal.binaries.withType(StaticLibraryBinarySpec) { spec ->
|
|
|
|
|
spec.headerDirs.each {
|
|
|
|
|
from(it) {
|
|
|
|
|
into 'include'
|
|
|
|
|
// We don't want to include any of the .cpp files that are in some of the header directories
|
|
|
|
|
exclude '**/*.cpp'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
from(spec.staticLibraryFile) {
|
2015-06-10 10:40:49 -04:00
|
|
|
into 'lib'
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
hal.binaries.withType(SharedLibraryBinarySpec) { spec ->
|
|
|
|
|
from(spec.sharedLibraryFile) {
|
2015-06-10 10:40:49 -04:00
|
|
|
into 'lib'
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// We rename the libHALAthena.so object to libHALAthena_shared.so
|
|
|
|
|
rename('(libHALAthena)(.so)', '$1_shared$2')
|
|
|
|
|
|
|
|
|
|
// Finally, include all of the shared library objects from the ni directory
|
|
|
|
|
from(project.file('../ni-libraries')) {
|
2015-06-10 10:40:49 -04:00
|
|
|
into 'lib'
|
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
|
|
|
exclude 'genlinks'
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
task wpilibcSimZip(type: Zip) {
|
|
|
|
|
description 'Creates the include zip file for wpilibc'
|
|
|
|
|
group 'wpilib'
|
|
|
|
|
baseName 'WPILibCSim'
|
|
|
|
|
destinationDir = project.buildDir
|
|
|
|
|
into 'sim/include'
|
|
|
|
|
from "${sim}/include"
|
|
|
|
|
from "${shared}/include"
|
2015-04-26 19:19:57 -04:00
|
|
|
from "../build/simulation/gz_msgs/generated"
|
2015-08-13 23:17:19 -07:00
|
|
|
from '../networktables/ntcore/include'
|
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
|
|
|
from '../hal/include'
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Add the dependency on the wpilib_nonsharedStaticLibrary task to the wpilibc task. Because of the gradle lifecycle,
|
|
|
|
|
// this cannot be done purely with dependsOn in the task, as the static library task doesn't exist yet. Same goes for
|
|
|
|
|
// the networkTablesStaticLibrary task and the two HAL tasks below
|
2015-09-25 22:04:00 -04:00
|
|
|
tasks.whenTaskAdded { task ->
|
|
|
|
|
if (task.name == 'wpilib_nonsharedStaticLibrary') {
|
|
|
|
|
wpilibcZip.dependsOn task
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Add the networktables static library as a dependency
|
2015-09-24 21:58:28 -04:00
|
|
|
project(':networktables:ntcore').tasks.findAll {
|
|
|
|
|
it.name == 'armNtcoreStaticLibrary'
|
|
|
|
|
}.each {
|
|
|
|
|
wpilibcZip.dependsOn 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
|
|
|
}
|
|
|
|
|
|
2015-09-24 21:58:28 -04:00
|
|
|
|
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
|
|
|
// Add the hal static and shared libraries as a dependency
|
2015-09-25 22:04:00 -04:00
|
|
|
project(':hal').tasks.whenTaskAdded { task ->
|
|
|
|
|
if (task.name == 'hALAthenaStaticLibrary' || task.name == 'hALAthenaSharedLibrary') {
|
|
|
|
|
wpilibcZip.dependsOn task
|
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If doxygen exists on the command line, then add the doxygen task as dependency of the wpilibcZip task
|
|
|
|
|
if (checkDoxygen()) {
|
|
|
|
|
wpilibcZip.dependsOn doxygen
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Attempts to execute the doxygen command. If there is no exception, doxygen exists, so return true. If there's
|
|
|
|
|
// an IOException, it doesn't exist, so return false
|
|
|
|
|
boolean checkDoxygen() {
|
|
|
|
|
try {
|
|
|
|
|
'doxygen'.execute()
|
|
|
|
|
true
|
|
|
|
|
} catch (IOException e) {
|
|
|
|
|
false
|
|
|
|
|
}
|
|
|
|
|
}
|