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
|
|
|
#!/usr/bin/env bash
|
|
|
|
|
|
|
|
|
|
##############################################################################
|
|
|
|
|
##
|
|
|
|
|
## Gradle start up script for UN*X
|
|
|
|
|
##
|
|
|
|
|
##############################################################################
|
|
|
|
|
|
2016-07-02 16:32:14 -07:00
|
|
|
# Attempt to set APP_HOME
|
|
|
|
|
# Resolve links: $0 may be a link
|
|
|
|
|
PRG="$0"
|
|
|
|
|
# Need this for relative symlinks.
|
|
|
|
|
while [ -h "$PRG" ] ; do
|
|
|
|
|
ls=`ls -ld "$PRG"`
|
|
|
|
|
link=`expr "$ls" : '.*-> \(.*\)$'`
|
|
|
|
|
if expr "$link" : '/.*' > /dev/null; then
|
|
|
|
|
PRG="$link"
|
|
|
|
|
else
|
|
|
|
|
PRG=`dirname "$PRG"`"/$link"
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
SAVED="`pwd`"
|
|
|
|
|
cd "`dirname \"$PRG\"`/" >/dev/null
|
|
|
|
|
APP_HOME="`pwd -P`"
|
|
|
|
|
cd "$SAVED" >/dev/null
|
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
|
|
|
|
|
|
|
|
APP_NAME="Gradle"
|
|
|
|
|
APP_BASE_NAME=`basename "$0"`
|
|
|
|
|
|
2016-07-02 16:32:14 -07:00
|
|
|
# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
|
|
|
|
|
DEFAULT_JVM_OPTS=""
|
|
|
|
|
|
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
|
|
|
# Use the maximum available, or set MAX_FD != -1 to use that value.
|
|
|
|
|
MAX_FD="maximum"
|
|
|
|
|
|
|
|
|
|
warn ( ) {
|
|
|
|
|
echo "$*"
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
die ( ) {
|
|
|
|
|
echo
|
|
|
|
|
echo "$*"
|
|
|
|
|
echo
|
|
|
|
|
exit 1
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
# OS specific support (must be 'true' or 'false').
|
|
|
|
|
cygwin=false
|
|
|
|
|
msys=false
|
|
|
|
|
darwin=false
|
2016-07-02 16:32:14 -07:00
|
|
|
nonstop=false
|
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
|
|
|
case "`uname`" in
|
|
|
|
|
CYGWIN* )
|
|
|
|
|
cygwin=true
|
|
|
|
|
;;
|
|
|
|
|
Darwin* )
|
|
|
|
|
darwin=true
|
|
|
|
|
;;
|
|
|
|
|
MINGW* )
|
|
|
|
|
msys=true
|
|
|
|
|
;;
|
2016-07-02 16:32:14 -07:00
|
|
|
NONSTOP* )
|
|
|
|
|
nonstop=true
|
|
|
|
|
;;
|
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
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
CLASSPATH=$APP_HOME/gradle/wrapper/gradle-wrapper.jar
|
|
|
|
|
|
|
|
|
|
# Determine the Java command to use to start the JVM.
|
|
|
|
|
if [ -n "$JAVA_HOME" ] ; then
|
|
|
|
|
if [ -x "$JAVA_HOME/jre/sh/java" ] ; then
|
|
|
|
|
# IBM's JDK on AIX uses strange locations for the executables
|
|
|
|
|
JAVACMD="$JAVA_HOME/jre/sh/java"
|
|
|
|
|
else
|
|
|
|
|
JAVACMD="$JAVA_HOME/bin/java"
|
|
|
|
|
fi
|
|
|
|
|
if [ ! -x "$JAVACMD" ] ; then
|
|
|
|
|
die "ERROR: JAVA_HOME is set to an invalid directory: $JAVA_HOME
|
|
|
|
|
|
|
|
|
|
Please set the JAVA_HOME variable in your environment to match the
|
|
|
|
|
location of your Java installation."
|
|
|
|
|
fi
|
|
|
|
|
else
|
|
|
|
|
JAVACMD="java"
|
|
|
|
|
which java >/dev/null 2>&1 || die "ERROR: JAVA_HOME is not set and no 'java' command could be found in your PATH.
|
|
|
|
|
|
|
|
|
|
Please set the JAVA_HOME variable in your environment to match the
|
|
|
|
|
location of your Java installation."
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# Increase the maximum file descriptors if we can.
|
2016-07-02 16:32:14 -07:00
|
|
|
if [ "$cygwin" = "false" -a "$darwin" = "false" -a "$nonstop" = "false" ] ; then
|
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
|
|
|
MAX_FD_LIMIT=`ulimit -H -n`
|
|
|
|
|
if [ $? -eq 0 ] ; then
|
|
|
|
|
if [ "$MAX_FD" = "maximum" -o "$MAX_FD" = "max" ] ; then
|
|
|
|
|
MAX_FD="$MAX_FD_LIMIT"
|
|
|
|
|
fi
|
|
|
|
|
ulimit -n $MAX_FD
|
|
|
|
|
if [ $? -ne 0 ] ; then
|
|
|
|
|
warn "Could not set maximum file descriptor limit: $MAX_FD"
|
|
|
|
|
fi
|
|
|
|
|
else
|
|
|
|
|
warn "Could not query maximum file descriptor limit: $MAX_FD_LIMIT"
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# For Darwin, add options to specify how the application appears in the dock
|
|
|
|
|
if $darwin; then
|
|
|
|
|
GRADLE_OPTS="$GRADLE_OPTS \"-Xdock:name=$APP_NAME\" \"-Xdock:icon=$APP_HOME/media/gradle.icns\""
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# For Cygwin, switch paths to Windows format before running java
|
|
|
|
|
if $cygwin ; then
|
|
|
|
|
APP_HOME=`cygpath --path --mixed "$APP_HOME"`
|
|
|
|
|
CLASSPATH=`cygpath --path --mixed "$CLASSPATH"`
|
2015-09-24 20:26:49 -04:00
|
|
|
JAVACMD=`cygpath --unix "$JAVACMD"`
|
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 build the pattern for arguments to be converted via cygpath
|
|
|
|
|
ROOTDIRSRAW=`find -L / -maxdepth 1 -mindepth 1 -type d 2>/dev/null`
|
|
|
|
|
SEP=""
|
|
|
|
|
for dir in $ROOTDIRSRAW ; do
|
|
|
|
|
ROOTDIRS="$ROOTDIRS$SEP$dir"
|
|
|
|
|
SEP="|"
|
|
|
|
|
done
|
|
|
|
|
OURCYGPATTERN="(^($ROOTDIRS))"
|
|
|
|
|
# Add a user-defined pattern to the cygpath arguments
|
|
|
|
|
if [ "$GRADLE_CYGPATTERN" != "" ] ; then
|
|
|
|
|
OURCYGPATTERN="$OURCYGPATTERN|($GRADLE_CYGPATTERN)"
|
|
|
|
|
fi
|
|
|
|
|
# Now convert the arguments - kludge to limit ourselves to /bin/sh
|
|
|
|
|
i=0
|
|
|
|
|
for arg in "$@" ; do
|
|
|
|
|
CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
|
|
|
|
|
CHECK2=`echo "$arg"|egrep -c "^-"` ### Determine if an option
|
|
|
|
|
|
|
|
|
|
if [ $CHECK -ne 0 ] && [ $CHECK2 -eq 0 ] ; then ### Added a condition
|
|
|
|
|
eval `echo args$i`=`cygpath --path --ignore --mixed "$arg"`
|
|
|
|
|
else
|
|
|
|
|
eval `echo args$i`="\"$arg\""
|
|
|
|
|
fi
|
|
|
|
|
i=$((i+1))
|
|
|
|
|
done
|
|
|
|
|
case $i in
|
|
|
|
|
(0) set -- ;;
|
|
|
|
|
(1) set -- "$args0" ;;
|
|
|
|
|
(2) set -- "$args0" "$args1" ;;
|
|
|
|
|
(3) set -- "$args0" "$args1" "$args2" ;;
|
|
|
|
|
(4) set -- "$args0" "$args1" "$args2" "$args3" ;;
|
|
|
|
|
(5) set -- "$args0" "$args1" "$args2" "$args3" "$args4" ;;
|
|
|
|
|
(6) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" ;;
|
|
|
|
|
(7) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" ;;
|
|
|
|
|
(8) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" ;;
|
|
|
|
|
(9) set -- "$args0" "$args1" "$args2" "$args3" "$args4" "$args5" "$args6" "$args7" "$args8" ;;
|
|
|
|
|
esac
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# Split up the JVM_OPTS And GRADLE_OPTS values into an array, following the shell quoting and substitution rules
|
|
|
|
|
function splitJvmOpts() {
|
|
|
|
|
JVM_OPTS=("$@")
|
|
|
|
|
}
|
|
|
|
|
eval splitJvmOpts $DEFAULT_JVM_OPTS $JAVA_OPTS $GRADLE_OPTS
|
|
|
|
|
JVM_OPTS[${#JVM_OPTS[*]}]="-Dorg.gradle.appname=$APP_BASE_NAME"
|
|
|
|
|
|
2016-09-01 20:30:37 -07:00
|
|
|
# by default we should be in the correct project dir, but when run from Finder on Mac, the cwd is wrong
|
|
|
|
|
if [[ "$(uname)" == "Darwin" ]] && [[ "$HOME" == "$PWD" ]]; then
|
|
|
|
|
cd "$(dirname "$0")"
|
|
|
|
|
fi
|
|
|
|
|
|
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
|
|
|
exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" org.gradle.wrapper.GradleWrapperMain "$@"
|