ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vitaly Stulsky" <vitaly_stul...@yahoo.com>
Subject RE: Patch: JAVAC dependency tracking and multiple src paths handling
Date Thu, 11 May 2000 16:29:22 GMT


> -----Original Message-----
> From: Roger Vaughn [mailto:rvaughn@seaconinc.com]
> Sent: Thursday, May 11, 2000 5:53 PM
> To: ant-dev@jakarta.apache.org
> Subject: Re: Patch: JAVAC dependency tracking and multiple src paths handling
>
>
> Conor MacNeill wrote:
> >
> > Vitaly,
> >
> > Interestingly I have also been working on dependency tracking and multiple
> > source paths.
> >
> >...
> >
> > 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 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.
> >
> > Cheers
> >
>
> I was about to start on the same problem when I saw this series of
> messages appear.  My approach to the dependencies was to define a
> separate task, as Conor did.  My approach, however, involves no changes
> to the javac task - the dependency generator/checker would delete any
> out of date .class files, thus forcing javac to recompile them
> naturally.  It could instead touch the affected .java files, but this
> would make cvs do extra work on commits and updates, affect backup
> systems, etc.  As I had planned on using Jikes as the dependency
> generator, this approach was guaranteed to be a bit slower.
>
> I haven't done the work yet, but if we want to see a *third* solution,
> I'm still set to do it.

I think will be better if we'll discuss all advantages and disadvantages here
and specify our demands for dependency tracking. If we will identify them,
we'll make the work much faster than releasing different approaches.
It is my opinion.

> My comments - I really like the separate element approach of Conor's
> srcdirs.  On the other hand, I kinda like the integrated dependency
> checks in Vitaly's solution.  It's likely to be faster since it seems to
> show less file system access than either Conor's or my approach.
>
> BTW, on the direct/indirect question - I spent quite a bit of time
> thinking this one through last year while using jikes/make.  Direct
> dependencies are going to be the biggest problem, but it is possible to
> show *real* indirect dependencies.  Consider this:
>
> public interface A {
> 	static final int x = 1;
> }
>
> public interface B extends A {
> 	static final int y = x + 2;
> }
>
> public class C implements B {
> 	private int z = y;
> }
>
> Ok, it's unlikely, but possible. :-)  Because of the way constants are
> handled by Java, C is definitely dependent on A.

Hm, I did think about such cases before ...
I have to analyse this code and will send you the results of my investigation
later.

> The only complaint I ever had about the jikes dependency system was
> that, even though I know c.class depends on a.java, b.java, and c.java,
> I can't see that c.class would ever depend on a.class or b.class (which
> dependencies jikes *does* generate).
>
> Anyway, it seems indirect dependencies are unlikely, but possible.  I
> would vote for including an "indirect" switch in any of the solutions so
> it can be turned off or on.  Adding indirect recompiles where they
> aren't needed adds a *lot* of build time.
>
>
> Roger Vaughn


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Mime
View raw message