New Build System

I reworked the build system over the last couple of days. It’s now composed of the following:

  • build.xml: the master Ant build script. Responsible for building the core, all backends, extensions and docs
  • build-template.xml: a template Ant script used to build all projects. Invoked by the master build script with appropriate parameters for a project’s classpath, jars that should go into the output jar and so on.

That’s about it. As a result, the release/nightly builds now have the following structure:


docs/
extensions/
armeabi/
armeabi-v7a/
sources/
gdx-$extensionname-sources.jar
gdx-$extensionname.jar
gdx-$extensionname-natives.jar
armeabi/
armeabi-v7a/
sources/
gdx-$projectname-sources.jar
gdx-$projectname.jar
gdx-$projectname-natives.jar

The core and backend jars are in the root folder of the distribution. The armeabi/ and armeabi-v7a/ folder contain the natives for Android, the gdx-$projectname-natives.jar contain the natives for the respective desktop project.

The extensions folder has the same setup for extensions (jars + desktop natives jars + arm binaries).

In other news: i removed the audio analysis and decoder classes from the core, they are now in gdx-audio. I’ll have those finished by the end of the day, including the mpg123 decoder. Stb TrueType has been moved to its own extension as well (gdx-stb-truetype).

You can now easily build your own distribution by invoking:


ant -f build-new.xml

This will create a dist/ directory containing all the jars and natives for both core and extension projects as outlined above. Only requirement: ant needs to be on your $PATH, JAVA_HOME needs to point to your JDK installation.

You can also build individual projects via:


ant -f build-new.xml gdx-$projectname

More things to come 😀

4 thoughts on “New Build System

  1. Great season’s cleanup!
    However, checking out from HEAD SVN and building via “ant”, Android natives ARMEABI/V7A won’t get copied in the “dist” directory as they should and the “extensions” directory is missing the same natives (libstbtruetype.so); everything is there in the libgdx-nightly-latest.zip package btw.

  2. Studying the new build system, it seems everything is as it should if i would set the “build-natives” property to “true” in the “build.xml” file, but then i need a way to choose which natives to build since i’m just targeting linux64/android and this is increasingly difficult since some extensions, ie. gdx-bullet/gdx-audio, need natives as well.

    It would be cool to have ant to check for the existence for each toolchain before invoking it, or is there any ant param to ignore toolchain invocation errors that i’m not aware of?

  3. Good point. My current setup is to have all the cross compilers installed on a 64-bit Linux box (MinGW32, MinGW64, Gcc with m32 and m64 support, Android NDK). Building all of libgdx but only selecting a subset of native build targets would be a nice to have i guess. Once i transitioned everything to jnigen i will add that option. For the moment you will have to manually edit the build.xml files in each projects jni/ folder and comment every target you don’t want to build for.

Leave a Reply

Your email address will not be published.