Ant Best Practices: Define Proper Target Dependencies
Posted on by Julian Simpson
Wondering what this post is about? Have a look here.
Last time I wrote, it was about reusing paths. Tonight, it’s about the dependency graph. My [N]Antcall is evil post goes into some detail about dependency graphs. Let’s just agree here that Ant targets tend to accumulate dependencies. The point that Eric makes is that the dependency graph (otherwise known as the dependency tree) grows over time as you add targets. Being a thing that accumulates over time, the graph can get crufty. That target that was just a short term thing while Bob worked on a refactoring exercise (oh, the irony) is now central to your build. So from time to time you need to clean the dependencies out, like that burned cheese that melts off of pizzas and sticks to the bottom of the oven.
Some projects seem to run into trouble and throw dependencies out completely. Umm, good luck with that. Eric suggests a half-way house approach: a few well known targets that contain dependencies on lesser known but functional targets for the more experienced to use at their own risk. I can go along with that.
My last thought is this: your default build should never depend on a clean target. Leave it to the compiler to have a go at working out what it should do. If you use Continuous Integration, you can make a little target that depends on clean just for that case. Your fellow developers will thank you.
