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)) {
|
2015-06-26 09:51:29 -04:00
|
|
|
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)) {
|
2015-06-26 09:51:29 -04:00
|
|
|
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')
|
2015-06-10 09:08:43 -04:00
|
|
|
}
|
|
|
|
|
linker.withArguments { args ->
|
|
|
|
|
args << '-rdynamic'
|
|
|
|
|
args.remove('-m32')
|
|
|
|
|
}
|
|
|
|
|
staticLibArchiver.executable = compilerPrefix + staticLibArchiver.executable
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-06-10 16:05:45 -04:00
|
|
|
// Workaround for OS X. Macs for some reason want to use Xcode's gcc
|
2015-06-12 16:56:41 -04:00
|
|
|
// (which just wraps Clang), so we have to explicitly make it so
|
2015-06-10 16:05:45 -04:00
|
|
|
// that trying to compile with Clang will call gcc instead
|
2015-06-10 09:08:43 -04:00
|
|
|
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'
|
2015-08-13 12:33:05 -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'
|
2015-06-10 09:08:43 -04:00
|
|
|
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')
|
|
|
|
|
}
|
2015-06-12 16:56:41 -04:00
|
|
|
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) {
|
2015-08-19 11:12:54 -04:00
|
|
|
// 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
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|