I tend to sympathize with the assertion since certainly as my build scripts
have grown in complexity, I have found that I would greatly benefit from the
same structuring functionality commonly found in general purpose scripting
languages that support modularity, reuse and extension, but that are missing
or lacking in Ant.
To be sure, <import>, <macrodef>, <scriptdef>, Antlib, namespaces, and
others address many of these issues, and are welcome, powerful and useful
additions to Ant, making it more manegeable than ever before. However, they
have also come at the cost of unresolved edge cases and ungainly syntax.
I offer as an example what can be done when the basis of a build script is
not a new language, but an existing, general purpose scripting language. As
an experiment, I attempted to mimic Ant's style and organization as a
language extension of python, i.e. packaged as a python module such that
build scripts are pure python. Thus, build authors benefit from python's
cross-platform scripting capabilities and mature structuring fuctionality.
The project's admittedly unimaginative working title is 'pant'.
In pant, I ported the main concepts of target, task, project, fileset,
javac, copy, and delete, among others. Here is what a simple build file
looks like, my hope is that it would be readily comprehensible by Ant users
even if they don't know much python:
# build.py - example pyant build script
import os
from pant import *
project = Project(name = "test", default = "build")
class properties(Target):
classesdir = "build/classes"
srcdir = "src"
jarname = "test.jar"
class compile(Target):
depends = properties
def run(self):
javac(src = properties.srcdir,
destdir = properties.classesdir)
class clean(Target):
depends = properties
def run(self):
delete(dir = properties.classesdir)
class jar(Target):
depends = properties
def run(self):
jar(
destfile = properties.jarname,
basedir = properties.srcname,
destdir = properties.classesdir)
class build(Target):
def run(self):
clean()
compile()
jar()
Notes:
0. Everything in this example is pure python. There are no modifications to
the language itself.
1. Targets are defined by subclassing pant.Target.
2. The depends class variable of a subclass of Target is a list of other
Target subclasses and is analgous to the depends attribute of Ant's target
element.
3. The body of a Target subclass's run method is analogous to the body of an
Ant target's element content. Within the run method's body, any legal
python code may be executed and normal scoping rules apply. After all
dependent targets are run, if any, the run method of a Target is called, if
defined.
4. Targets may be run by simply calling them, i.e. clean().
5. Targets may be defined in another python script and imported using
python's import keyword.
6. Parameters may be passed to Targets when calling them, e.g.
clean(dir="some/dir")
didge
> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 21, 2004 10:09 AM
> To: Ant Developers List
> Subject: RE: Blog "Complex build systems need a real language" found
>
>
> > From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> >
> > > From: Peter Reilly [mailto:[EMAIL PROTECTED]
> > >
> > > According to the last entry, they are currently
> > > using a 45,000 line ant script =-O
> > > which one of the team is reducing to ~700 lines by
> > > using a custom dependency task.
> >
> > I didn't read all the thread completely, but I heartedly
> > agree with Peter that much of the complexity of an Ant
> > script can be removed by developing custom tasks/types.
> >
> > You go to Java to encapsulate complex processes, which are
> > then exposed as much simpler high level tasks hiding all the
> > coding complexities. Using Python in AAP, or Ruby might allow
> > easier/faster programming than Java, but Java can do it all
> > nonetheless, and I personally know Java much better than
> > Python and Ruby ;-)
> >
>
> And with scriptdef, you can write your tasks just the same in any
> supported
> scripting language, if it will fit your needs.
>
> Jose Alberto
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
