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
>
