ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vitaly Stulsky" <>
Subject RE: Patch: JAVAC dependency tracking and multiple src paths handling
Date Thu, 11 May 2000 16:17:34 GMT
> Interestingly I have also been working on dependency tracking and multiple
> source paths.
Yeah, it is intersting.

> For multiple source paths, I submitted a patch for multiple source paths a
> while back. I chose to use a comma to separate the source paths since it
> seemed likely to offend the Windows folks and the Unix folks equally :-) The
> patch was not applied because of the use of that comma. There was also some
> desire to support elements instead of just an attribute, something like
>   <javac>
>     <srcdir name="xyz">
>     <srcdir name="abc">
>   </javac>

This is better than my approach. I agree with you.

> I have changed my approach now to use the more "forgiving" ways of
> Project.translatePath. I have added a method to Project called
> translatePathInternal. Whereas translatePath will translate a path to the
> local platform conventions, this new method translates paths, whether
> specified with ":/" or ";\", to a platform independent format based on ':'
> and '/' but supporting DOS drive style paths (C:\...). This path can then be
> tokenized on the ':' character to build the source paths vector. So you can
> specify the path in either Windows or Unix style and it should work on
> either platform. I'm not sure how other platforms react :-) I still haven't
> added the element approach yet.

> For dependency tracking I took a different approach from you. I separated
> dependency analysis into a new task <depend>. The depend task builds a
> dependency file by analysing the given set of class files (either a
> directory or a jar). Javac uses the dependency file to determine which
> classes are affected by classes being recompiled. In theory the dependency
> file could be built in some other way but still be used by Javac. The
> dependency format is pretty simple and could be changed easily.

It is good, but I tried to avoid intermediate files. Of course, intermediate
creation significiantly increase overall dependency tracking performance.
In theory better to analyze .java files and in intermediate files store
information not only about affected classes, but about classes internals.

For example:
     public class A

       public void meth() {
     Assume that only meth use class B methods. If we change somthing besides
     we shouldn't recompile

Java files analysis approach covers compiler optimization issues too.

> Example usage
>  <javac srcdir="${src1.dir}:${src2.dir};${src3.dir}"
>            destdir="${build.classes}"
>            classpath="${build.classpath}"
>            debug="on"
>            deprecation="on"
>            depfile="${build.dir}/depfile.txt">
>  </javac>
>  <depend src="${build.classes}" depfile="${build.dir}/depfile.txt" />
> I also only follow direct relationships. Say you have a scenario of A
> depends on B and B depends on C but A does not depend on C. If you change C,
> my approach will only compile C and B but not A. My feeling is that if A
> does not depend directly on C, changes to C cannot affect A through B. I'm
> still thinking about that :-)

I think that you've selected the right approach. It isn't necessary to recompile
A without direct relation to changed classes.

> I can't really say which approach is better. I include my source code (and a
> set of diffs) here to let people see an alternative approach.



Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.

View raw message