Automate Everyday Tasks with Ant

Posted by Alex Schearer on Monday, September 22, 2008 · Leave a Comment

Alright, so I’ve got to confess that I love to write makefiles and similar things. There’s something immediately rewarding about automating commonly performed tasks. That’s why I thought I would share some of the cool things you can do with ant.

Ant is a tool written in Java which aims to improve the build process. It does this by providing a layer of abstraction so that your build files can run across platforms. In addition, ant provides a lot of useful tasks to bear on the build process effectively letting you write mini-scripts. Awesome.

Enough talk, let’s take a look at how ant can speed up developing your next (Slick) game.

Setting up your development environment

Pesky native libraries make setting up Slick a real pain, especially for beginners…

<!-- Set up the game environment by preparing the natives. -->
<target name="setup" depends="check-setup" unless="setup.exists">
    <mkdir dir="lib/natives" />
    <unzip src="lib/natives-win32.jar" dest="lib/natives" />
    <unzip src="lib/natives-mac.jar" dest="lib/natives" />
    <unzip src="lib/natives-linux.jar" dest="lib/natives" />
</target>

<!-- Determines whether setup has been run. -->
<target name="check-setup">
    <condition property="setup.exists">
        <available file="lib/natives" type="dir" />
    </condition>
</target>

So, let’s say you’ve got a directory, lib which has three jar files in it:

lib/natives-win32.jar
lib/natives-mac.jar
lib/natives-linux.jar

Wouldn’t it be nice if you could extract all of the native libraries and dump them into a lib/natives directory? Well that’s exactly what the above script does. Even better it will only create the lib/natives directory once! The check-setup target looks for the lib/natives directory and if it exists sets the property setup.exists to true thus aborting the process. Great!

Compiling and archiving

Next up the hello world of build processes. Let’s say you want to compile all your code in src into class files in bin. Naturally, the next step is to archive your bytecode and any resources in res so you can distribute everything…

<!-- Compile and archive the game. -->
<target name="build">
    <antcall target="compile" />
    <antcall target="archive" />
</target>

<!-- Compile the code put results into bin. -->
<target name="compile">
    <mkdir dir="bin" />
    <javac destdir="bin" debug="on">
        <src path="bin" />
        <classpath>
            <!-- Assumes Slick is in your lib dir! -->
            <pathelement path="lib/slick.jar" />
        </classpath>
    </javac>
</target>

<!-- Jar compiled code and place result into current dir. -->
<target name="archive">
    <jar destfile="./game.jar" manifest="manifest.txt">
        <fileset dir="bin" />
        <fileset dir="res" />
    </jar>
</target>

Alright, so now you can call ant build to compile and archive the code! Notice that this will include a manifest saved as manifest.txt. If you’re using Slick then I encourage you to adopt my manifest as a template, here it is. Finally, notice that this creates game.jar feel free to rename things, but make sure things are consistent across your ant file!

Running the game

Last in this brief tutorial is a task to automate running the game. It turns out that you need to pass some command line arguments to the JVM in order to run Slick. This is necessary for lwjgl to find its native libraries, yuck. However, with this simple script you (or the noobs who want to play your game) will never have to worry about it.

<!-- Run the game. -->
<target name="run" depends="setup,build">
    <java jar="./game.jar" fork="true" failonerror="true">
        <jvmarg value="-Djava.library.path=lib/natives" />
    </java>
</target>

This last command will try to execute the jar created by the build command passing the JVM the necessary arguments. Notice that it “depends” on setup and build. That’s because it wouldn’t work if the natives weren’t in place and the jar didn’t exist, so it makes sure they are by calling those tasks first.

So there you have it; just a few handy tricks for playing with Slick. If you want to see some more cool tricks then check out my build file. I’ve got some additional commands such as cleaning the workspace and preparing your jar for distribution as a webstart. If you have any cool ant tricks let me know in the comments!

Finally, here’s the build file we just created. build.xml

Tags: