I've long felt uncomfortable with ant as a build management tool. I thought that my uneasiness stemmed from the verbose XML used for describing tasks, and the lack of default dependency resolution. Today, email from a UMLGraph user struggling with a complex ant task made me realize another problem: lack of observability.
In the Unix-based make the language for specifying actions consists simply of commands that a user can type into the Unix shell. As a result, I can directly interpret the output of a well-written Makefile, and construct a mental image based on the underlying commands. Moreover, I can execute those commands by hand to see their effect, and examine the intermediate files they generate. Finally, I can also copy-paste shell commands to a Makefile. All these affordances, allow me to construct a direct mapping between the execution model of make and a model I can observe and interact with (that of an interactive shell).
The design of ant doesn't offer this capability. Actions and their results are hidden ant tasks, which are only available within the ant engine. The only way this capability could be provided would be through an-ant specific shell or debugger. Both are expensive and unattractive propositions (do I really want to learn another shell or debugger interface, just for the sake of ant?) It looks like, Stu Feldman, the man behind make picked in the 1970s the right design.Read and post comments, or share through
Last modified: Thursday, March 15, 2007 4:04 pm
Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.