GANT-9 raises the point that Gant does not reason about the target dependency structure. This can be (perhaps should be) solved by introducing a dependency analysis pre-pass into Gant. An alternate solution is to change the underlying semantics of what Gant scripts are. Currently a Gant script is an executable script that scripts Ant tasks. An alternative semantics is for a Gant script to be a builder script that generates a graph of nodes describing the dependencies and actions -- cf. SCons. The operational semantics can then be determined by visitors over the generated graph.
The advantage of this change to being builder based is that it allows for the easy introduction of file dependency relationships. Currently, Gant (and Ant) require the tasks to manage all file dependency relationships. Ant is simply a declarative expression of relationships between targets. Gant extends this by allowing arbitrary Groovy code to control the task scripting. This means file dependency relationships can be worked on in Gant scripts. However the lessons of Make, Rake, Rant, SCons, etc. is that as well as having targets and tasks, it is good to structure the relationships between files. The danger is that things get too low level -- Make, Rake, and Rant suffer this problem. And yet, it is a feature that can be high level -- it is for the programmer of the build script to use things appropriately.
Rant and Rant have 'task' and 'file'. These are just two different sorts of node in the dependency data structure. Gant's targets were initially called tasks since they related directly to Rake's and Rant's task. However, Gant tasks were really related to Ant's targets and so the name was changed.
A proposal for developing Gant is to keep target as a callable entry point, but to introduce task and file as ways of expressing dependency information.