ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rogervau...@yahoo.com>
Subject RE: The RIGHT Direction for ANT (was Re: Problem using script tas k)
Date Tue, 09 Jan 2001 21:55:33 GMT
Jikes is definitely a good start, and I used these
features to significantly decrease my build times in
pre-Ant days.

Be aware, though, that (at least last time I used
Jikes) certain gotchas exist: it is a bit overzealous
at producing dependencies, listing as dependants both
.java and .class files, and more importantly, it used
to have a problem producing the correct dependencies
if your class output dir was different than your
source dir.  The need to massage the dependencies
Jikes produced led me away from that path and into
simply using Jikes' "deep compile" (the +F option),
which implicitly does all of the dependency checking
for you.

Still, it's the only thing I've seen that will even
try to produce Java dependencies.

--- David Dabbs <Ddabbs@Zefer.com> wrote:
> All,
> 
> There is a readily available, though not Java-based,
> dependency generator:
> Jikes. 
> For instance, the following Jikes command 
> 
> 	jikes +DR=dependencies.txt +CSO +B +F -classpath
> %CLASSPATH%
> JavaCC.java
> 
> yields these results:
> 
>
D:/dev/JAKART~1/src/main/org/apache/tools/ant/taskdefs/JavaCC.java
> :
> Lorg/apache/tools/ant/taskdefs/JavaCC;
>     Ljava/lang/Object;
>     Lorg/apache/tools/ant/types/Path;
>     Ljava/io/File;
>     Lorg/apache/tools/ant/types/Reference;
>     Ljava/lang/String;
>     Lorg/apache/tools/ant/BuildException;
>
d:/dev/jakarta-ant/src/main/org/apache/tools/ant/types/FileSet.java
> :
> Lorg/apache/tools/ant/types/FileSet;
>     Lorg/apache/tools/ant/types/DataType;
>     Lorg/apache/tools/ant/types/Reference;
>     Lorg/apache/tools/ant/BuildException;
>     Ljava/io/File;
>     Lorg/apache/tools/ant/Project;
>     Ljava/util/jar/Manifest;
>     Lorg/apache/tools/ant/types/PatternSet;
>     Ljava/lang/String;
>     Lorg/apache/tools/ant/DirectoryScanner;
>     Lorg/apache/tools/ant/FileScanner;
>     Lorg/apache/tools/ant/types/FileSet;
>     Ljava/util/Vector;
>     Ljava/lang/StringBuffer;
>     Ljava/io/BufferedReader;
>     Ljava/lang/Exception;
>     Ljava/io/FileInputStream;
>     Ljava/io/InputStreamReader;
>     Ljava/lang/IllegalArgumentException;
>     Ljava/lang/Object;
>     Ljava/util/Map;
>     Ljava/util/Set;
>     Ljava/util/Stack;
>     Ljava/util/HashSet;
>     Ljava/util/Iterator;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/lang(Object.class)
> : Ljava/lang/Object;
>
d:/dev/build/ant/classes/org/apache/tools/ant/types/Path.class
> :
> Lorg/apache/tools/ant/types/Path;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/io(File.class) :
> Ljava/io/File;
>
d:/dev/build/ant/classes/org/apache/tools/ant/types/Reference.class
> :
> Lorg/apache/tools/ant/types/Reference;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/lang(String.class)
> : Ljava/lang/String;
>
d:/dev/build/ant/classes/org/apache/tools/ant/BuildException.class
> :
> Lorg/apache/tools/ant/BuildException;
>
d:/dev/build/ant/classes/org/apache/tools/ant/types/DataType.class
> :
> Lorg/apache/tools/ant/types/DataType;
>
d:/dev/build/ant/classes/org/apache/tools/ant/Project.class
> :
> Lorg/apache/tools/ant/Project;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/util/jar(Manifest.class)
> :
> Ljava/util/jar/Manifest;
>
d:/dev/build/ant/classes/org/apache/tools/ant/types/PatternSet.class
> :
> Lorg/apache/tools/ant/types/PatternSet;
>
d:/dev/build/ant/classes/org/apache/tools/ant/DirectoryScanner.class
> :
> Lorg/apache/tools/ant/DirectoryScanner;
>
d:/dev/build/ant/classes/org/apache/tools/ant/FileScanner.class
> :
> Lorg/apache/tools/ant/FileScanner;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/util(Vector.class)
> : Ljava/util/Vector;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/lang(StringBuffer.class)
> :
> Ljava/lang/StringBuffer;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/io(BufferedReader.class)
> :
> Ljava/io/BufferedReader;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/lang(Exception.class)
> :
> Ljava/lang/Exception;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/io(FileInputStream.class)
> :
> Ljava/io/FileInputStream;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/io(InputStreamReader.class)
> :
> Ljava/io/InputStreamReader;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/lang(IllegalArgumentException.class)
> :
> Ljava/lang/IllegalArgumentException;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/util(Map.class) :
> Ljava/util/Map;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/util(Set.class) :
> Ljava/util/Set;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/util(Stack.class) :
> Ljava/util/Stack;
> d:\jdk\1.2.2\jre\lib\rt.jar/java/util(HashSet.class)
> : Ljava/util/HashSet;
>
d:\jdk\1.2.2\jre\lib\rt.jar/java/util(Iterator.class)
> : Ljava/util/Iterator;
> 
> 
> To calculate the dependency information for Foo.java
> source:
> 
> 	Look in a dependency cache file for a cached
> Timestamp
> 	if Timestamp hasn't changed
> 		Retrieve cached MD5 of the file's information
> 	else
> 		Recalculate the MD5 signature for Foo.java's
> contents
> 	Call jikes for Foo.java's dependency graph
> 	For each source file-based dependency found (omit
> jars, at least
> java.*):
> 		Retrieve or recalculate the dependent file's
> dependency
> signature
> 		add that signature to the Foo.java's dependency
> signature
> 	endfor
> 	Add classpath, java version, etc. to derived
> dependency signature
> 	Retrieve cached dependencySignature
> 	If signature != cachedDependencySignature
> 		rebuild/add to rebuild list
> 	
> This is similar to how tools such as CONS handle
> dependence checking. Yes,
> you're scanning files every time, but for
> non-trivial systems this is a
> small price compared to unnecessary compilation, at
> least with C/C++.
> Another benefit is that you've implicitly added the
> build script to the
> dependency. If one changes an item that is digested
> in (e.g. classpath ot
> javac options) the target(s) should be rebuilt. 
> 
> I'm considering using this same scheme, albeit minus
> the Jikes dependency
> checking, for a Manifest file driven build process
> based on Ant.
> 
> 
> cheers,
> 
> David
> 
> 
> -----Original Message-----
> From: Jerry Huth [mailto:jerry.huth@Sun.COM]
> Sent: Tuesday, January 09, 2001 12:57 PM
> To: ant-dev@jakarta.apache.org
> Subject: The RIGHT Direction for ANT (was Re:
> Problem using script task)
> 
> 
> 
> This discussion about whether or not ANT should have
> more advanced
> features such as templates is amusing because the
> obvious answer is
> that if your software system is so large that you
> need such advanced
> features, then your build system should include both
> a
> dependency-generation program as well as a
> dependency-reading program.
> 
> ANT and MAKE are dependency-reading programs.  They
> are meant to read
> dependency scripts and fire the actions.  They are
> not meant as
> human-written scripting languages for large software
> systems.
> Dependency-generation programs are those that write
> out the dependency
> scripts: they generate the ANT or MAKE build scripts
> so that humans
> don't have to.
> 
> As software systems grow in size, the folly of
> trying to use the
> dependency scripts to define your whole software
> build system becomes
> more and more apparent.  No matter how many advanced
> features you add
> to your dependency-reading program, you will always
> be able to build
> large software systems easier using a
> dependency-generation program in
> combination with the dependency-reading program.  
> 
> In fact, the only reason to add advanced features to
> ANT or MAKE is to
> allow them to be used (however awkwardly) for
> medium-sized software
> projects.  For large software projects it is clear
> that using the two
> programs in combination is infinitely easier than
> trying to build the
> whole system with only a dependency-reading program.
>  Indeed, MAKE
> has become exorbitantly bloated with "advanced"
> features over the
> years, but still it is completely inadequate for
> large software
> systems unless it is used in combination with a
> dependency-generation
> program.
> 
> Mathematically the reason why using the two programs
> together is
> easier is that the dependency-generation program
> requires only
> Constant time effort (it is not dependent on the
> size of the software
> system being built), whereas dependency scripts
> always require at
> least some O(n) effort (n is the number of lines of
> source code being
> built).  Furthermore, using a dependency-generation
> program allows you
> to minimize the O(n) effort by putting the "smarts"
> of the build
> system in the dependency-generation program, thus
> allowing the O(n)
> scripts to be reduced to their smallest possible
> size.  Indeed, when
> used with a good dependency-generation program, the
> O(n) effort is so
> small that it is easily handled by the source code
> developers
> themselves.
> 
> Theoretically if a software system is "sufficiently
> uniform" than a
> feature as simple as templates could allow ANT or
> MAKE to be used
> without a dependency-generation program; but of
> course as software
> systems grow in size, their degree of uniformity
> inevitably lessens
> due to the increasing need for automation and other
> advanced build
> features, so there is always a point at which the
> use of a separate
> dependency-generation program is easier.
> 
> Ultimately, software build systems should provide
> the most advanced
> build features to the end-user (the software
> developer) while reducing
> the O(n) build script maintainence effort to its
> minimal value.  And
> this is precisely why using the two programs in
> combination is so
> effective: coding the advanced features of a build
> system in the
> Constant-time part (the dependency-generation
> program) will always
> require less effort than coding them in the O(n)
> part (the dependency
> scripts).
> 
> What this means for the future direction of ANT is
> that we shouldn't
> repeat the mistakes of MAKE by continuing to pile on
> more and more
> features of dubious usefullness.  Instead we should
> focus our efforts
> on providing an ANT file generator that is
> sufficiently general to be
> useful to the software community at large.
> 
> The irony of using a dependency-generator program is
> that when you
> have one you only need very basic features in the
> dependency-reading
> program.  ANT doesn't need any more features, it
> needs a companion ANT
> file generator program!
> 
> ---
> 
> Jerry Huth
> Sun Microsystems
> (650) 786-4658
> jerry.huth@sun.com
> 
> 
> 
>
-------------------------------------------------------------------------
> Jason Rosenberg wrote:
> > 
> > > On 1/6/01 9:40 PM, "Jason Rosenberg"
> <jason@squaretrade.com> wrote:
> > >
> > > > Ant is procedural, and that is what I want. 
> It is close to being
> useful,
> > > > to date, but just needs to add a very small
> set of features to close
> the
> > > > case.  Simply admitting that it is procedural
> would really clear the
> way.
> > > > Let's stop beating around the bush.
> > >
> > > Nope. Let's not. There are things that Ant
> needs. IMHO, turning into
> > > something procedural isn't one of them. I'd
> rather just write my
> > > buildscripts in JavaScript if that were the
> case.
> > >
> > 
> > Well, I got into this debate because I wanted to
> have reusable templates
> > which are applied across a large set of like
> modules, etc.  And, as we
> have
> > seen, Ant 1.2 is still not adequate in terms of
> templating, etc.  So, this
> > leaves us with having to use JavaScript, via the
> script task, if we want
> > to have any sort of elegance with Ant.  So, for
> now, not only are you
> > right in saying that if you want to do anything
> procedural, you should
> > use JavaScript, you also need to add that you
> really end up doing
> > everything in JavaScript anyway, even when you are
> using Ant.
> > 
> > > I come down to the opinion that calling
> something data or code is pretty
> > > tough. After all, software is just data at some
> point. :) However there
> is a
> > > visceral line drawn about what Ant is good for,
> and at what point it's
> not.
> > > That line has been labeled with the somewhat,
> but sort of useful terms
> of
> > > "procedural vs. declarative". Neither term is
> totally appropriate. But
> we
> > > use them anyway :)
> > >
> > 
> > Ant is a build management tool.  It's purpose is
> to build software.  This
> > means doing things like javac and javadoc and copy
> and ejbjar, etc.
> > These are all procedural tasks.  If you want to be
> able to represent
> > a software build module declaratively, then you
> need to be able
> > to define it as a data object, with attributes
> which define how to
> > build it.  In order to do this constructively, you
> simply have to have
> > templates or sub-routines, etc.
> > 
> > > > Yes, I think the beauty of Ant is that it has
> the power to keep
> > > > things simple and human readable.  I like the
> <execute-task>
> > > > idea mentioned by someone on another topic, or
> possibly a
> > > > simple case:
> > > >
> > > > <case property="caseProperty">
> > > >   <if value="1" execute="doMainCompile"/>
> > > >   <if value="2" execute="doPartialBuild"/>
> > > >   <default execute="showErrorAndFaile"/>
> > > > </case>
> > >
> > > But here you are saying you want a "if" target
> implementation that could
> > > take any set of attributes and do something.
> "<execute-target>" only
> does
> > > just that. It's a difference. And, imho, it's a
> big one.
> > >
> > 
> > I don't understand what you said here.
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ant-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> ant-dev-help@jakarta.apache.org
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

Mime
View raw message