ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Barclay <>
Subject RE: auto dependency generation?
Date Thu, 11 Apr 2002 13:51:56 GMT

> <depend> really answers the question "What do I need to 
> *recompile* due to a
> change in my source?" It does that by looking at the class 
> file to see which
> other classes a class uses. ...
> In your case, you are interested in dependencies in the 
> opposite direction -
> which classes do I need to exist in order to compile my 
> class? Normally the
> Javac compiler will handle this issue....

Wasn't someone asking about cases that <depend> doesn't cover
(that is, the few kinds of source dependencies not reflected 
in class files, or new source dependencies)?

Theoretically at least, might there be a place for a full source 
dependency checker?  It would do a full dependency check on the 
current source (instead of looking at class files with: 1) not-quite-
full and 2) not-quite-current dependency information).  

It could operate as <depend> does, deleting class files to force
the <javac> to recompile whatever needed to be recompiled.

<pie-in-the-sky probably-level="yeah, right">

Actually, wouldn't it be ideal if compilers wrote out dependency
information during regular compilation?

That is, every time the compiler compiled a Java source file, it would
write out an explicit list of the classes on which the newly-compiled 
class depends.

- All dependencies would be captured (not just the 95% represented in 
  class files).
- Parsing and semantic analysis for dependency extraction wouldn't 
  take any extra time because it would use what the compiler has to
  do anyway (and it wouldn't be a separate step).

(I worked on a compiler-like tool (for VHDL) that wrote out dependency 
information like that for downstream tools to use.)

Of course, since class files contain most of the dependencies, too bad
they can't at least list the remaining dependencies for this purpose
(even if they shouldn't affect class-loading behavior).



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message