Page History

Cross Builds

The build is configured to support cross builds, that is, the ability to build an SDK for a platform other than the one you are building from. There are multiple gradle files located in buildSrc which represent specific compile targets. These include:

• win.gradle
• mac.gradle
• linux.gradle
• android.gradle
• ios.gradle
• armv6sf.gradle
• armv6hf.gradle

Each of these have specific prerequisites that must be met before they can be built. win.gradle can only be used on Windows, mac.gradle on Mac, and linux.gradle on Linux. Android can be cross built from Mac, Windows, or Linux so long as the Android SDK and NDK are installed and the build knows where to find them. iOS can be cross built on Mac. ARM (soft float and hard float) can be cross built from Linux.

By default, the OpenJFX build system will only build the SDK for the desktop platform you are building from. To ask it to build for a specific compile target, you must pass a COMPILE_TARGETS property to the build system, instructing it which to build. This is a comma separated list. Assuming you have already setup the prerequisites for building ARM (for example, when targeting the Raspberry PI), you would invoke gradle like this:

rbair$ gradle -PCOMPILE_TARGETS=armv6hf

Cross building for ARM hard float

In order to cross-compile for Linux/ARM you first need to obtain the libraries to compile against. You'll need several of the same tools as for a Linux desktop build, so you should start by making sure you can build for the desktop, following the instructions above.

For the cross-compilation step you should start with a Raspberry Pi with the Raspbian operating system installed on it, as described at OpenJFX on the Raspberry Pi. Then you need to install some additional libraries:

sudo apt-get install \
  libatk1.0-dev \
  libdirectfb-dev \
  libgtk2.0-dev \
  libgstreamer0.10-dev \
  libgstreamer-plugins-base0.10-dev \
  libudev-dev \
  libxml2-dev \
  libxslt1-dev \
  libxtst-dev

This will pull over the libraries from the Raspbian repository.

Now you need to shut down the Pi (run sudo halt and wait half a minute or so) and remove the SD card from it. Connect the card to a Linux x86 machine that has a working copy of OpenJFX on it. Then, from the OpenJFX directory run:

 buildSrc/crosslibs/crosslibs-armv6hf.sh

This will copy files from your Pi's file system to a directory crosslibs at the same level as your OpenJFX working copy. It will then download a cross-compiler for ARM and install it in the same place. When the script has completed you should see:

Done.

You can now replace your SD card in you Raspberry Pi; you won't need to run crosslibs-armv6hf.sh again unless OpenJFX is modified to require additional or updated libraries.

You are now ready to run a full cross-compile for ARM hard float:

gradle -PBUILD_NATIVES=true -PCOMPILE_TARGETS=armv6hf

Note that when you run with an OpenJFX build you need to prepend your new jfxrt.jar to the boot class path. For ARM cross-builds you also need to add jfxrt-graphics.jar from an existing JDK. For example,

/opt/jdk1.8.0/bin/java \
    -Xbootclasspath/p:build/armv6hf-sdk/rt/lib/ext/jfxrt.jar:\
        /opt/jdk1.8.0/jre/lib/ext/jfxrt-graphics.jar \
    -jar BrickBreaker.jar 

This is so that you can use the closed source font libraries that are not available in OpenJFX. When we have a font implementation in OpenJFX using open source libraries this requirement will be removed.

Anchor
customizing-the-build customizing-the-build

Customizing the Build

The build can be customized fairly extensively through the use of Gradle properties. Gradle provides many ways to supply properties to the build system. However the most common approach will be to use a gradle.properties file located in the rt directory. Simply make a copy of gradle.properties.template and then edit the resulting gradle.properties file to customize your build.

rbair$ cp gradle.properties.template gradle.properties

The gradle.properties file that you have just created is heavily documented and contains information on all the different configuration options at your disposal. Some of the most common are:

Arguably the most important property in the build is the JDK_HOME property. Almost all other properties are derived automatically from this one. The JDK_HOME is by default based on the java.home System property, which is set automatically by the JVM based on which version of Java is executed. Typically, then, the version of Java you will be using to compile with will be the version of Java you have setup on your path. You can of course specify the JDK_HOME yourself. Note also that on Windows, the version of the JDK you have set as JDK_HOME will determine whether you build 32 or 64 bit binaries.

Testing

The next basic task which you may want to perform is test. The test task will execute the unit tests. You generally will execute the top level test because unlike with Ant, Gradle will only re-execute those tests which have changed (or were dependent on code that was changed) on subsequent runs. You can of course execute gradle cleanTest in order to clean all the test results so they will run fresh. Or, if you want to execute only those tests related to a single project, you can do so in the normal fashion:

rbair$ gradle :base:test
The CompileOptions.useAnt property has been deprecated and is scheduled to be removed in Gradle 2.0. There is no replacement for this property.
:base:processVersion UP-TO-DATE
:build-tools:generateGrammarSource UP-TO-DATE
:build-tools:compileJava UP-TO-DATE
:build-tools:processResources UP-TO-DATE
:build-tools:classes UP-TO-DATE
:build-tools:jar UP-TO-DATE
:base:compileJava UP-TO-DATE
:base:processResources UP-TO-DATE
:base:classes UP-TO-DATE
:base:compileTestJava UP-TO-DATE
:base:processTestResources UP-TO-DATE
:base:testClasses UP-TO-DATE
> Building > :base:test > 3411 tests completed, 45 skipped

Gradle gives helpful output during execution of the number of tests completed and the number skipped without dumping out lots of output to the console (unless you opt for --info). Also, once the tests complete, an HTML report is dumped to the project's build/reports/test directory (for example, modules/base/build/reports/test):

For the sake of performance, most of the tests are configured to run in the same VM. However some tests by design cannot be run in the same VM, and others cannot yet run in the same VM due to bugs or issues in the test. In order to improve the quality of the project we need to run as many tests as possible in the same VM. The more tests we can run on pre-integration the less likely we are to see failures leak into master. Being able to run 20,000 tests in a minute is extremely useful, but not possible, unless they run in the same VM. Something to keep in mind.