Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 40231 invoked from network); 18 Feb 2000 19:57:50 -0000 Received: from ux4.sp.cs.cmu.edu (128.2.198.104) by locus.apache.org with SMTP; 18 Feb 2000 19:57:50 -0000 Received: from TURTLE.CORAL.CS.CMU.EDU by ux4.sp.cs.cmu.edu id aa22960; 18 Feb 2000 14:56 EST Date: Fri, 18 Feb 2000 14:56:11 -0500 From: William Uther To: ant-dev@jakarta.apache.org cc: Sebastian Kanthak , Alexey Demakov Subject: Re: implicit dependencies Message-ID: <315374.3159874571@turtle.coral.cs.cmu.edu> In-Reply-To: <003f01bf7a24$4c5f7980$8c5ebac2@kazbek.ispras.ru> Originator-Info: login-id=will; server=postoffice.srv.cs.cmu.edu X-Mailer: Mulberry (MacOS) [1.4.4, s/n S-100002] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Alexey Demakov 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 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 :-}