Ant rocks. I’m now using it to automate the (ever-increasingly complex) build process for my book. Since I spend so much time complaining about things I hate, I thought I’d expound briefly on something I like.
For those of you who maintain development projects manually, and have ever missed a step and released something that didn’t compile/install/run/whatever, you owe it to yourself to check out Ant. It allows you to define an unlimited number of targetsin your project and define dependencies between them. For instance, I build versions of my book in HTML, PDF, Word, and text, and so each of these are separate targets. The HTML target does four things:
<target name="html" depends="init">
<copy todir="${html}">
<fileset dir="${css}">
<include name="*.css"/>
</fileset>
</copy>
<copy todir="${html}/images">
<fileset dir="${images}">
<include name="**/*.${png}"/>
</fileset>
</copy>
<java classname="com.icl.saxon.StyleSheet" fork="yes">
<arg line="-ds ${xml}/diveintopython.xml ${xsl}/html.xsl"/>
<classpath>
<pathelement path="${saxon}"/>
</classpath>
</java>
<exec executable="python" failonerror="yes">
<arg line="${py}/colorize.py ${html}"/>
</exec>
</target>
- Before we start, this target depends on another target called “init”, so Ant will run that first. In my case, the “init” target just ensures that all the build directories I need are created properly.
- First, copy all the .css files from the css directory to the html directory. ${css} and ${html} are Ant properties, defined earlier in the configuration file.
- Second, recursively copy all the .png files from the images directory to a subdirectory of the html directory. This will recreate the directory structure of the original images directory, but only copy the .png files.
- Third, invoke the XSL parser (via Java), passing in the command-line arguments that specify the source XML file and the XSL stylesheet to use. Again, ${xml} and ${xsl} are properties that I set earlier in the configuration file.
- Fourth, call the Python script to colorize the program examples within the generated HTML. If the script fails, stop the build immediately.
Now, I used to have .bat files to do all this sort of thing, but Ant offers several advantages:
- It’s smart. I can specify which errors are fatal, and Ant will stop mid-task. Before, if my html.bat crapped out when calling the XSL parser (because I had invalid XML, or invalid XSL, or both), it would still go merrily along and run the colorize Python script anyway. Ant is smart enough to stop if the XSL parser fails.
- It’s powerful. The “recursively copy all the files that match this pattern and maintain the directory structure” feature rocks my world. Ant can also create zip files by cherrypicking files from different directories and assembling them in the structure you want within the zip file. This is something I had previously written a Python script to do, which worked, but it was inflexible and hard to maintain.
- It’s flexible. If I want to build HTML and PDF but not anything else, I can call “ant html pdf”. If I want to build everything, I can call “ant all”. If I change my directory structure, all I have to do is change the directory definitions at the top of the configuration file, and everything still works. If I want to build the book in a different language like (French), I can create a separate configuration file that includes only the directory definition changes, and I get to re-use all my target code.
- It’s cross-platform. I intend to move solely to Linux within the next year, and that requires weaning myself of all my Windows crutches. The Windows-specific syntax I used in the .bat files is now one less thing to worry about.
Try Ant. It will rock your world.
