ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rvau...@seaconinc.com>
Subject Re: Patch: JAVAC dependency tracking and multiple src paths handling
Date Thu, 11 May 2000 14:53:03 GMT
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.

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.

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

Mime
View raw message