Xamarin Problems & Build Changes

I’ve been checking on the progress on the Xamarin front. As you may remember, we are phasing out the Xamarin backend.

It seems the problems with the Xamarin backend are not resolvable. Michael Bayne from ThreeRings has fixed up many things, but it seems many of our users are still having issues despite those fixes. I’m in favor of not releasing the Xamarin backend in the upcoming 0.9.9 release. I would tag or branch the Git repository to keep the Xamarin backend available, then remove all remnants of the Xamarin backend from the repo. The nightlies and release would not contain any Xamarin related things anymore (drastically cutting down the download size of libgdx as well). What are your thoughts on this matter?

Also, i want to kill the unholy Ant build script of death in favor of our Maven build. Reason being that the setup-ui will be transitioned to use Gradle in the near future, and Gradle requires our stuff to be in a Maven repository. By forcing myself to fix up the Maven build (it is up to date and fully functional, including gdx-freetype and gdx-bullet), i can guarantee that the Maven releases are pristine. I’d also like to get input on this.


Welcome your new overlord: Gradle

I’ve been sick the last few days, and figured i’d learn Gradle. I created a Gradle based libgdx template, which you can start using now. It will eventually replace our current Setup-UI to make my life more enjoyable. IT will also allow you to build and run your libgdx projects on the CLI, Eclipse, IntelliJ and even Netbeans. And on top of that, you’ll not have to juggle any JARs or native libraries anymore, everthing is taken care off for you. You can update to different version of gdx, and easily include extensions or other 3rd party libraries. So, what is this magical Gradle?

Gradle is a build and dependency management system, using Groovy and some domain specific language sugar. A build system is responsible for compiling your application and packaging it up. A dependency management system allows you to define which 3rd party libraries you want to use, and the system will automatically pull those libraries in for you. Provided the libraries are available in some sort of repository. The most established type of repository in Java land are Maven repositories, with Maven Central being the global central hub to which almost all things get published to.

Here’s what defining such dependencies looks like in Gradle for a libgdx project that also uses the FreeType and Bullet extensions (no GWT and iOS yet):

The core project references the gdx core API, the FreeType extension and the Bullet extension. The desktop project additionally references the gdx LWJGL backend, and the native libraries for gdx core, FreeType and Bullet in their desktop incarnations. The desktop project also depends on the core project, so it will pull in all the code from the core project, as well as any of the core project’s dependencies!

The Android is a little special due to how things work in Android land. Sadly, we have to reference the FreeType and Bullet extension again even though we also depend on the core project, which should pull in the core project’s dependencies. It’s a long story, and i’m a bit fed up with the mess that is Android’s build system (and no, the new Gradle Android build system isn’t awesome either…). Anyways, that’s how its done in Android land.

You’ll also notices those dependencies ending in e.g. natives-armeabi or natives-debug. These just contain native code in form of shared libraries, e.g. your beloved libgdx.so and consorts.

Adding a new dependency is as simple as finding it on Maven Central, then adding it to that Gradle build file. Once to the core project’s dependency, and once again to the Android project’s dependencies, the desktop project gets things from the core project as it should be.

Say you want to add Kryo by Nate. First you go to Maven Central and search for Kryo, which will bring up the following:

Just click on the first entries latest Version (2.21). On the next site you’ll see the group id (com.esotericsoftware.kryo), the “artifact id” (kryo) and the version (2.21). To add this as a dependency to your Gradle-based libgdx project, just add the following to the dependency sections of the core and android projects

That’s it. Now you can have Gradle regenerate your Eclipse/Idea projects, et voila, you can now use Kryo! Best of all, you have no JAR files in your project directory, for which SVN/Git/Hg will thank you.

You can also change the version of dependencies in the Gradle build file, and it will automatically get the correct libraries for you. No manual copying of things, not chance of messing things up!

You can find the Gradle template over on Github, with full instructions. Go try it out! I’ll add GWT and RoboVM support in the following days. Please report any issues. Eventually i’ll package this up and add a tiny GUI for initial project creation, just like the old setup UI. However, any updates of dependencies and so on will be done by you in the Gradle build file just as illustrated above. This will make that setup GUI extremely simple. More time will be spent on the Gradle build files. E.g. it’s already possible to create ZIP distributions for desktop projects and APKs for Android projects with the current Gradle system. I’ll likely extend that to allow you to create EXEs and App Bundles for Mac OS X and maybe even DEB files for Debian/Ubuntu.

One note: IDE integration of Gradle is still a weak point. IntelliJ Idea doesn’t cope well with multi-module projects. The Eclipse Gradle plugin by SpringSource is OKish, and you can actually use the current system with it. But i sense there will be issues cropping up when used for more complex things.

Also, the Android project uses the new Android Gradle based build on the command line, but uses the Ant based build in Eclipse/IntelliJ Idea. Until the Eclipse ADT plugin understands Gradle that won’t change. Oh, and the Android Studio/IntellJ Idea plugin doesn’t work properly either. It’s all a bit of a hack at the moment, but here’s hoping for a bright and clean future. If you want to give your eyes cancer, check out the Android project’s Gradle build file responsible for making it work with the CLI, Eclipse and Android, and fix the non-handling of native libraries with the new Android Gradle build system. Luckily you’ll not have to touch that file, unless you want to add flavors to your Android project.