ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject Re: implicit dependencies
Date Fri, 18 Feb 2000 19:56:11 GMT
-- Alexey Demakov <demakov@ispras.ru> wrote:
[snip]
> How is it possible to manage implicit dependencies with ANT?
[snip]
> Is there way to manage such dependencies with ANT?
> Or it's "only Java" build tool and all dependencies are managed by javac?
[snip]

I can't see any way to manage such dependancies with ANT.  I'd love to be
shown incorrect.  I also believe that ANT/javac doesn't handle this case
even for java.  You have to clean and rebuild to make sure you catch
everything.  It builds new .class files when the corresponding .java file
is changed, but not any other files that might depend upon a changed
interface.  Again, I'd love to be shown incorrect.

-- Sebastian Kanthak <sebastian.kanthak@muehlheim.de> wrote in a message
titled "jikes & extdirs patch":

> For the future (this or next weekend) I'm thinking of implementing
> code to use the nice jikes feature to generate make-like dependancy
> files. You probably know the problem, that will arise, if you define a
> final variable (constant) in a class and use it in another class. When
> you change the value of the final now, the other class won't be
> recompiled.
> 
> jikes has a feature to generate files in which it records all
> dependancies. You could then use these files to add all files to the
> buildlist, that haven't changed, but are relying on files having
> changed. Anybody interessted in this or do you think it is unneccesary
> (I haven't used it extensively yet)?

So, if you do this, it would be cool if it was done in a way that would
also work with other 'makedepends' systems.

The CodeWarrior java IDE has a very nice dependancy system for java.  It
recompiles .java files that depend upon changed code.  Particularly nice is
that it doesn't just have a single level of change.  It seems to look at
the severity of the change.  Here are some example severity levels:

private interface changed  (this might be useful for regenerating javadocs)
protected interface changed
package interface changed
public interface changed

When you change an interface it recompiles only those files that depend
upon what changed.  Changing an implementation doesn't force dependant
files to be recompiled unless the corresponding interface changes.
Changing a protected interface doesn't force recompilation of programs that
only depend upon the public interface.  Changing a doc comment need not
force much to recompile at all.

Thoughts on finding out which level has changed:

My first thought was to use javap to extract the interface so it can be
compared to previous versions.  Using the -public, -package, etc options
allow you to extract the interface.  A simple 'diff' with the old version
will then tell you what has changed.  This has two drawbacks.  The output
is a series of text strings.  It doesn't catch changed 'static final'
variables mentioned by Sebastian above.

Another option is to use ClassLoader.defineClass() to get a Class instance
and then use the reflection API (Class.getDeclaredConstructors(),
Class.getDeclaredFields() and Class.getDeclaredMethods() and possibly
Class.getDeclaredClasses()) to get the API in a usable form to check for
differences.

If you are using a makedepend system without multiple levels, then you just
set all those generated dependancies at the 'private' level.  If you don't
want to implement the multi-level change detection then you can just use
File.lastModified() and make that a 'public' level change.  Then you can
develop the components separately.

Thoughts, comments?

\x/ill            :-}


Mime
View raw message