I think the original person wanted a Java based tool though..so a Perl
solution probably wont work.


> -----Original Message-----
> From: Peter Vogel [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 11:35 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Can someone tell me what is so great about Ant?
> 
> 
> Check out "cons" www.dsmit.com/cons/
> 
> It does dependency scanning and maintains an
> MD5 signature for determining whether a rebuild
> of a file is necessary, the signature incorporates
> ALL the inputs (including the compiler and the compiler
> command line) that lead to a derived object so
> it is quite good at rebuilding what it should and not
> rebuilding what it should not.
> 
> -Peter 
> 
> > -----Original Message-----
> > From: King Dale [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, February 06, 2001 10:25 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: Can someone tell me what is so great about Ant?
> > 
> > 
> > I don't mean to be a troll, but I have been trying to find a 
> > good Java build
> > tool. I have seen lots of hype about Ant and have looked at 
> > it and I'd just
> > like to say I am not that impressed. I am hoping someone can 
> > show me where I
> > am wrong. Maybe there are some better ways to do things as 
> > all I have seen
> > are simple build script examples.
> > 
> > It is supposedly a powerful tool that replaces make, but I 
> > find lots of
> > problem with it as a build tool. Here is a simple example. 
> > Let's use the
> > build.xml directly from the documentation:
> > 
> > <project name="MyProject" default="dist" basedir=".">
> > 
> >   <!-- set global properties for this build -->
> >   <property name="src" value="." />
> >   <property name="build" value="build" />
> >   <property name="dist"  value="dist" />
> > 
> >   <target name="prepare">
> >     <!-- Create the time stamp -->
> >     <tstamp/>
> >     <!-- Create the build directory structure used by compile -->
> >     <mkdir dir="${build}" />
> >   </target>
> > 
> >   <target name="compile" depends="prepare">
> >     <!-- Compile the java code from ${src} into ${build} -->
> >     <javac srcdir="${src}" destdir="${build}" />
> >   </target>
> > 
> >   <target name="dist" depends="compile">
> >     <!-- Create the ${dist}/lib directory -->
> >     <mkdir dir="${dist}/lib" />
> > 
> >     <!-- Put everything in ${build} into the 
> > MyProject-${DSTAMP}.jar file
> > -->
> >     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" 
> > basedir="${build}" />
> >   </target>
> > 
> >   <target name="clean">
> >     <!-- Delete the ${build} and ${dist} directory trees -->
> >     <delete dir="${build}" />
> >     <delete dir="${dist}" />
> >   </target>
> > </project>
> > 
> > And let's create Main.java and Foo.java defined as follows:
> > public class Main
> > {
> >     public static void main( String[] args )
> >     {
> >         Foo.test();
> >     }
> > }
> > 
> > public class Foo
> > {
> >     public static void test()
> >     {
> >         System.out.println( "Foo.test()" );
> >     }
> > }
> > 
> > I run Ant and it builds correctly. But let's say I need to 
> change the
> > signature of Foo.test and I add a parameter, but I forget to 
> > make the change
> > in Main. If I run Ant again it will tell me that it built 
> > successfully, but
> > I have successfully built an inconsistent target. The code 
> > will not run
> > since Main was not recompiled.
> > 
> > Certainly I could write my own tasks and explicit rules to 
> > fix this, but all
> > I want to do is build, not write my own make tool. Or I could 
> > simply always
> > rebuild all files by deleting the generated classes, but then 
> > all Ant is is
> > a glorifed batch file. Perhaps others have some other ideas on this.
> > 
> > Something else I look for, but is extremely rare in make 
> tools is the
> > ability to handle that file dates can go backwards. For 
> > instance when using
> > an SCM tool and I am working on version 2.x and there is a 
> > problem found in
> > version 1.9. I will check out the source files for 1.9 but 
> > they will have
> > dates older than the current files and even though the files 
> > are different
> > they will not be built because the generated files are newer. 
> > One way for a
> > build tool to handle this is to maintain a build log that is 
> > consulted for
> > the next build. That build log says that file X with a 
> > certain timestamp was
> > generated from this list of files with timestamps. If any of 
> > the time stamps
> > are not equal to what is in the log, X is regernerated. The 
> > only build tool
> > I know of that does this sort of thing is omake in ClearCase.
> > 
> > Hopefully these will be taken as ideas for further improvement.
> > 
> > ---
> >  -- Dale King
> > 
> 

Reply via email to