You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Arun Katkere <ka...@praja.com> on 2000/07/21 02:10:41 UTC
Incremental Compilation and ant
Javac task filters the list of input source files to only those that are
newer than corresponding .class files. Which is great. But, not all files
that need to be recompiled are always recompiled. For instance, if we change
a method signature of a base class, all subclasses are not automatically
recompiled, creating an inconsistency.
Is there are solution for this problem (other than deleting the entire class
tree)?
-arun
RE: Incremental Compilation and ant
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
> >> I used to be of opinion that we should do this but I can't see any reason
> >> to at all anymore. Classfile analysis is probably the best of a bunch of
> >> bad choices. The reason is that the building of dependancies will end up
> >> being *slower* than deleting the whole tree and recompiling using
> >> jikes !!!
> >
> >Peter, Well I know you like Jikes :-) Not everyone, however, chooses to use
> >Jikes. I would like to see whether everyone not using Jikes is content to
> >delete their whole tree to guarantee that their compilations are valid.
>
> True but it seems like adding an ugly hack to Ant to workaround faults in
> shoddy compilers. *sigh* :P
Why somebody might not want to use jikes? ;o)
I share the opinion of Peter and Barrie at the current moment.
-1
However, if it really really need to be done, 3. would be for me the good
choice, i.e. dependency task which deletes the out-of-date class files,
and has nothing to do as such with javac task.
RE: Incremental Compilation and ant
Posted by Peter Donald <do...@mad.scientist.com>.
At 02:33 21/7/00 +1000, you wrote:
>> I used to be of opinion that we should do this but I can't see any reason
>> to at all anymore. Classfile analysis is probably the best of a bunch of
>> bad choices. The reason is that the building of dependancies will end up
>> being *slower* than deleting the whole tree and recompiling using
>> jikes !!!
>>
>
>Peter, Well I know you like Jikes :-) Not everyone, however, chooses to use
>Jikes. I would like to see whether everyone not using Jikes is content to
>delete their whole tree to guarantee that their compilations are valid.
True but it seems like adding an ugly hack to Ant to workaround faults in
shoddy compilers. *sigh* :P
>Personally I have never really liked having to add code, which does nothing,
>merely to force the compiler to behave in certain ways. Of course, it is
>necessary to do sometimes, but it is error prone. People forget to add these
>bits of code. All IMHO, of course.
Yup. Except for dependancy hacks when referencing other final static
variables (which are necessary when you just do classfile analysis anyway)
this can all be auto-generated and the user doesn't have to wrorry about
anything. It was how early iterations of many builder style programs did it
(namely early JBuilder and early TogetherJ). They may even still do it but
I don't use proggies to know :P
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
RE: Incremental Compilation and ant
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@mad.scientist.com]
>
>
>
> I used to be of opinion that we should do this but I can't see any reason
> to at all anymore. Classfile analysis is probably the best of a bunch of
> bad choices. The reason is that the building of dependancies will end up
> being *slower* than deleting the whole tree and recompiling using
> jikes !!!
>
Peter, Well I know you like Jikes :-) Not everyone, however, chooses to use
Jikes. I would like to see whether everyone not using Jikes is content to
delete their whole tree to guarantee that their compilations are valid.
> This can be fixed with a reference in B like
>
> private static final Class A_DEPEND = A.class;
> or
> private static final A = null;
>
> Another approach I used to use pre jikes is automatically
> generate files in
> each package that references each class. ie in each package a generated
> file like
>
> public class DependsCompilePack
> {
> public static final Class CLASS1_DEPEND = Class1.class;
> public static final Class CLASS2_DEPEND = Class2.class;
> public static final Class CLASS3_DEPEND = Class3.class;
> ...
> }
>
Personally I have never really liked having to add code, which does nothing,
merely to force the compiler to behave in certain ways. Of course, it is
necessary to do sometimes, but it is error prone. People forget to add these
bits of code. All IMHO, of course.
Conor
RE: Incremental Compilation and ant
Posted by Peter Donald <do...@mad.scientist.com>.
At 02:09 21/7/00 +1000, you wrote:
>I would like to have some discussion on this list about which approach, if
>any, we should adopt for this issue. Class file analysis, to extract
>dependencies, is not trivial and increases the amount of code in Ant quite a
>bit. People may also want to consider source file analysis. Personally I
>think class file analysis is both simpler and sufficient.
I used to be of opinion that we should do this but I can't see any reason
to at all anymore. Classfile analysis is probably the best of a bunch of
bad choices. The reason is that the building of dependancies will end up
being *slower* than deleting the whole tree and recompiling using jikes !!!
The only dependancy that I have noticed jikes doesn't catch is cases like
public class A
{
public static final <primitiveType> MY_CONSTANT = <blah>;
}
public class B
{
void method()
{
doSomething( A.MY_CONSTANT );
}
}
This can be fixed with a reference in B like
private static final Class A_DEPEND = A.class;
or
private static final A = null;
Another approach I used to use pre jikes is automatically generate files in
each package that references each class. ie in each package a generated
file like
public class DependsCompilePack
{
public static final Class CLASS1_DEPEND = Class1.class;
public static final Class CLASS2_DEPEND = Class2.class;
public static final Class CLASS3_DEPEND = Class3.class;
...
}
Then you just recompile each of these DependsCompilePack in each package
and everything should be updated. (I believe - at least it used to work in
1.1.7 :P)
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Incremental Compilation and ant
Posted by Peter Donald <do...@mad.scientist.com>.
At 05:10 20/7/00 -0700, you wrote:
>Javac task filters the list of input source files to only those that are
>newer than corresponding .class files. Which is great. But, not all files
>that need to be recompiled are always recompiled. For instance, if we change
>a method signature of a base class, all subclasses are not automatically
>recompiled, creating an inconsistency.
>
>Is there are solution for this problem (other than deleting the entire class
>tree)?
Use jikes compiler and add
<property name="build.compiler" value="jikes"/>
<property name="build.compiler.emacs" value="on"/>
<property name="build.compiler.warnings" value="true"/>
<property name="build.compiler.depend" value="true"/>
to your buildfile
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Incremental Compilation and ant
Posted by Peter Donald <do...@mad.scientist.com>.
At 04:50 21/7/00 +0200, you wrote:
>Fair enough--question though re. Jikes: if you simply ask it to compile
>every source file, will it correctly compile only those it needs to, and
>not up-to-date sources, even though you explicitly requested them? Or is
>it necessary to _only_ give it some entry point(s) such as main classes
>to make sure it is lazy enough?
I believe it will walk full tree from the main class (at least if you
specify dependancies). I have no idea if it will unconditionally recompile
or whether it will check file modify times - either way it is fast thou so
it really isn't an issue :P.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Incremental Compilation and ant
Posted by Jesse Glick <Je...@netbeans.com>.
Peter Donald wrote:
> My question remains - why create a massive workaround for crappy compilers
> when you already have a very very very fast compiler that does it for you.
> Integrating this into javac task is just penalising the decent compiler and
> hiding faults of bad compilers.
Fair enough--question though re. Jikes: if you simply ask it to compile
every source file, will it correctly compile only those it needs to, and
not up-to-date sources, even though you explicitly requested them? Or is
it necessary to _only_ give it some entry point(s) such as main classes
to make sure it is lazy enough?
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re: Incremental Compilation and ant
Posted by Peter Donald <do...@mad.scientist.com>.
At 03:50 21/7/00 +0200, you wrote:
>Warning: this is a long message...
It was wasn't it :P. Your analysis is correct and was actually very similar
to what I do with c files. The problem is that it is way overhead for
decent compilers (ie jikes). Jikes does exactly what you said already
(except without intermediate .dep files) so you would be duplicating work.
Jikes is also much much much much more efficient than any thing you can
write (no offense) - I believe it even makes sure it doesn't hit the
filesystem in a bad way I believe.
My question remains - why create a massive workaround for crappy compilers
when you already have a very very very fast compiler that does it for you.
Integrating this into javac task is just penalising the decent compiler and
hiding faults of bad compilers.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
Re: Incremental Compilation and ant
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> 1. Add the dependency analysis to Javac and perhaps a switch to decide
> whether to use it or not. This has been proposed by Vitaly Stulsky. I
think
> we still need to whole source code for this proposal.
Okay, I'll send all the code next week. I'll spend my weekend working upon
this code. It needs some formating and apache license adding.
Re: Incremental Compilation and ant
Posted by Jesse Glick <Je...@netbeans.com>.
Vitaly Stulsky wrote:
> In optimized code dependencies can be resolved only by java class
> parsing (class file doesn't contain full info).
Yup...that's why I noted that this would not work well with compiler
optimizations on. Hopefully Javac at least does not try anything too
clever with no -O specified.
> In general I agree with you and your algorithm looks pretty good. One
> thing we need too decide: do we need .dep files or no?
One reason to use them is that they should list only classes which were
present, in source form, in the compilation directory at the time you
did the last compilation. Library classes should not be listed. If you
skip the .dep files, then only dependencies present in source form at
the next compilation can be checked for timestamps (since you do not
know what is a library vs. a source class). Thus if a A depends on B and
B.java is removed (someone forgets that A is still using it), A would
not be recompiled, so the necessary compilation error will not happen
and the source is broken but you do not know about it.
You could maybe solve this by checking in the compile-time classpath
(inside JARs and so on) for the dependency classes if they were not
found in the source tree. I agree, avoiding .dep files if possible would
be better. But they are potentially more efficient.
I am definitely swayed by arguments that just using Jikes would solve
all this more quickly and sanely. However while working on a large Java
code base (NetBeans IDE) we have yet to find a single compiler that
compiles every file in the source tree. I just tried Jikes 1.06 and it
is very fast but it has some problems to compile our sources. Javac
1.2.2 does most of it, but chokes on a lot of inner-class constructions.
Javac 1.3 does almost everything but chokes on some different things.
FastJavac is much faster but has its own idiosyncrasies. In other words,
trusting one compiler with everything in a large project can be
difficult. Maybe that is not a good enough reason to make Ant more
complex.
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re: Incremental Compilation and ant
Posted by Vitaly Stulsky <vi...@yahoo.com>.
> Setup: somewhere there should be storage of dependencies. In my script,
> .java and .class files lived in the same directory (no -d option), and I
> added .dep files for each source as well in the same directory. Each
> .dep file was a text file with a list of dependencies, one per line,
> given as class names (outer classes only, no inner classes listed); it
> represents the dependencies in the source tree of the given class, not
> to include classes present in JARs and so on in the (non-source)
> classpath, nor including the class itself. Timestamp of the .dep file is
> significant. For efficiency, it would be possible to store a single deps
> database in some format, listing timestamp, dependent class name, and
> all source dependencies of that class. Or .dep files could be placed in
> a special separated directory.
It is neccessary to decide here do we want intermediate files generated
by ant?
If yes - dependancy tracking will work faster, but we need
to specify where to store this files cause this files could add some garbage
to distributive if will strore them in dest directory or add this garbage to
the source diectory.
If no - dependancy tracking will work slower, but we will not care about
this
files.
As for me, I like first, cause what the faster solution is beter for me.
> Algorithm:
>
> 1. Prepare list of classes to compile. Scan the source tree (given
> includes/excludes, etc.) for source files. A source file is out of date
> if any of the following are true:
>
> 1a. It has no .class file.
>
> 1b. Its .class file is older than the source file.
>
> 1c. It has no .dep file.
>
> 1d. Its .dep file is older than the source file.
>
> 1e. One or more of the source files listed in its .dep file is missing.
>
> 1f. One or more of the source files listed in its .dep file is newer
> than the considered source file.
>
> 2. Run the selected Java compiler on the source files thus gleaned. It
> should not matter how that compiler does dependency analysis, or even if
> it does any; all required files ought to have been explicitly listed
> anyway.
>
> 3. Again using the same list of source files, find the freshly-compiled
> .class files and parse them. A full bytecode library should not be
> necessary, only ability to parse the constant pool. All classes
> referenced at compile time should be listed as class constants in this
> pool. (My original script simply grepped the binary .class file for
> likely references using a conservative approximation, but doing it right
> should not be that hard.) Remember to search all inner-class files.
> (JDK-1.0-style package-private outer classes might be a problem here--it
> may be necessary to check the "source" attribute in the class file to
> handle these.)
There are some tricky compiler behaviours here. Sometimes you cannot
receive all dependancy info from constant pool. Do not forget about
optimizer! I analyzed javac generated bytecode (1.2.2) and compared it
to jikes. Jikes fro example remove from constant pool unused classes,
but javac stores it there. That's why you cannot rely on jikes generated
.class file and you can on javac generated. Exist a lot of complex examples
using interfaces, inheritance, inner classes and static variables where very
difficult for you to track dependancies (indirect dependencies).
Here is simple one:
public class A extends B {
public int a = 1;
public A() {
print();
}
public static void main(String args[]) {
new A();
}
}
public class B extends C {
public int b = 2;
void print() {
System.out.println(i);
}
}
public class C implements I {
public int c = 3;
}
public interface I {
static int i = 100;
}
"A" and "B" constant pools don't contain anything about I.
In optimized code dependencies can be resolved only by java class
parsing (class file doesn't contain full info).
[...]
In general I agree with you and your algorithm looks pretty good. One
thing we need too decide: do we need .dep files or no?
Vitaly
Re: Incremental Compilation and ant
Posted by Jesse Glick <Je...@netbeans.com>.
Stefan Bodewig wrote:
> JG> 1f. One or more of the source files listed in its .dep file is
> JG> newer than the considered source file.
>
> Shouldn't that be "newer than the considered _class_ file"? The source
> file won't change it's timestamp even after the recompile and this
> condition will hold true 'till eternity.
Quite right, amend that.
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
Re: Incremental Compilation and ant
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "JG" == Jesse Glick <Je...@netbeans.com> writes:
JG> Warning: this is a long message
Seems like I could add a disclaimer like this to every third message
of mine theses days. Hope this one is an exception.
JG> I'd like to add a suggestion for a variant of this.
While your approach - with a nit, see below - should work with every
compiler at first glance, I think we should make it depend on the
compiler in question nevertheless. This could be done transparently
for the user.
People like Peter will tell you - and I assume they are right - that
it would be quicker to remove all class files and do a full recompile
using jikes than to parse the class files afterwards. And jikes
dependency tracking seems to work quite reliable.
So I'd like to see this modified to - use an approach like yours
unless build.compiler==jikes. Use jikes dependency tracking otherwise.
JG> A source file is out of date if any of the following are true:
[...]
JG> 1f. One or more of the source files listed in its .dep file is
JG> newer than the considered source file.
Shouldn't that be "newer than the considered _class_ file"? The source
file won't change it's timestamp even after the recompile and this
condition will hold true 'till eternity.
Stefan
Re: Incremental Compilation and ant
Posted by James Duncan Davidson <du...@x180.com>.
on 7/21/00 6:50 AM, Jesse Glick at Jesse.Glick@netbeans.com wrote:
> I'd like to add a suggestion for a variant of this. Basically it would
> be one task, not two, which runs an incremental compilation and also
> computes dependencies.
Way back, I wanted to give the javac task the ability to stash a dependency
graph somewhere so that it could do this -- same thought. :)
> For efficiency, it would be possible to store a single deps
> database in some format, listing timestamp, dependent class name, and
> all source dependencies of that class. Or .dep files could be placed in
> a special separated directory.
I'd do a serialized object sitting at the base of the source tree that
contained the dependancies for the source tree.
.duncan
Re: Incremental Compilation and ant
Posted by Jesse Glick <Je...@netbeans.com>.
Warning: this is a long message...
Conor MacNeill wrote:
> 2. Add a separate dependency task which generates a dependency file. Javac
> would use that file to determine which files would need to be recompiled. I
> proposed a patch for this approach. It decouples the dependency analysis
> from the javac task
I'd like to add a suggestion for a variant of this. Basically it would
be one task, not two, which runs an incremental compilation and also
computes dependencies. Its advantages are that it should work with any
Java compiler, no matter how stupid its dependency analysis; it would be
transparent for the user to invoke (just like a normal compilation task,
give the source directory, non-source classpath, and a compiler version
to use); should (re-)compile exactly those files it needs to; should
behave sanely even if compilation of the same sources is done in the
interim without the dependency-tracking task (e.g. bare command-line
compiler). I wrote a Perl script a while back which mostly implements
it, though that script was kind of a mess and it would be much cleaner
as an Ant task.
Setup: somewhere there should be storage of dependencies. In my script,
.java and .class files lived in the same directory (no -d option), and I
added .dep files for each source as well in the same directory. Each
.dep file was a text file with a list of dependencies, one per line,
given as class names (outer classes only, no inner classes listed); it
represents the dependencies in the source tree of the given class, not
to include classes present in JARs and so on in the (non-source)
classpath, nor including the class itself. Timestamp of the .dep file is
significant. For efficiency, it would be possible to store a single deps
database in some format, listing timestamp, dependent class name, and
all source dependencies of that class. Or .dep files could be placed in
a special separated directory.
Algorithm:
1. Prepare list of classes to compile. Scan the source tree (given
includes/excludes, etc.) for source files. A source file is out of date
if any of the following are true:
1a. It has no .class file.
1b. Its .class file is older than the source file.
1c. It has no .dep file.
1d. Its .dep file is older than the source file.
1e. One or more of the source files listed in its .dep file is missing.
1f. One or more of the source files listed in its .dep file is newer
than the considered source file.
2. Run the selected Java compiler on the source files thus gleaned. It
should not matter how that compiler does dependency analysis, or even if
it does any; all required files ought to have been explicitly listed
anyway.
3. Again using the same list of source files, find the freshly-compiled
.class files and parse them. A full bytecode library should not be
necessary, only ability to parse the constant pool. All classes
referenced at compile time should be listed as class constants in this
pool. (My original script simply grepped the binary .class file for
likely references using a conservative approximation, but doing it right
should not be that hard.) Remember to search all inner-class files.
(JDK-1.0-style package-private outer classes might be a problem here--it
may be necessary to check the "source" attribute in the class file to
handle these.)
4. Create a fresh .dep file listing all those classes found in the
constant pool which are in fact present in the source tree (vs. library
or JRE classes). Issue a warning if a dependent class is present in the
source tree in .class but not in .java form (and still add a dependency
for it).
Now what happens is this: the first time the project is built, every
class will be given to the compiler since there are no .dep files.
Subsequently the user may modify some source files. On the next build,
certainly these files will be recompiled; any classes directly depending
on these modified classes should also be compiled, according to
information from the .dep files. (Note that unlike C/C++, dependency is
not transitive in Java, i.e. only direct dependencies need be
considered.) So a developer can always ask to compile the whole source
tree and get only recompilations which are necessary, or might be
necessary (in case an API might have been broken). Removals of source
files from the tree should also trigger recompilation of dependent files
(presumably displaying the correct compilation errors). Additions of
source files, or making modifications which change the list of
dependencies for a class, should also be treated correctly. It is safe
to compile a few files by hand, since the next proper build will find
that the .dep files are out of date and rebuild them. It should also be
safe to remove .dep files if you want to.
Note that I think you need to not just generate a .dep file but actually
recompile after just 1c. or 1d. holds, even though it seems you would
not, in order to ensure that removals of source files trigger
recompilations reliably.
It is necessary to make sure that compilation errors do not leave behind
an up-to-date .class file (which hopefully they do not).
There is only one exception I can think of to Java dependencies not
being transitive: a static final primitive/String constant defined in A,
and referenced in B as the value of another constant, and referenced in
C somehow, could make C's compiled form depend directly on A's source,
when using an optimizing compiler. I think this is a pretty rare case
(especially since runtime use of a JIT or HotSpot makes optimizations
like that close to useless). Maybe similar for final method inlining?
Someone should check the JLS on this but I think such dependencies are
officially pretty restricted, and it would be just as well to disable
optimization flags in this kind of situation.
I believe the above algorithm is correct, but as I said it is some time
since I really used it, so there might be some subtle gotchas. Comments
welcome...
Cheers,
-Jesse
--
Jesse Glick <ma...@netbeans.com>
NetBeans, Open APIs <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
RE: Incremental Compilation and ant
Posted by Barrie Treloar <Ba...@camtech.com.au>.
On Fri, 21 Jul 2000, Conor MacNeill wrote:
> 1. Add the dependency analysis to Javac and perhaps a switch to decide
> whether to use it or not. This has been proposed by Vitaly Stulsky. I think
> we still need to whole source code for this proposal.
>
> 2. Add a separate dependency task which generates a dependency file. Javac
> would use that file to determine which files would need to be recompiled. I
> proposed a patch for this approach. It decouples the dependency analysis
> from the javac task
>
> 3. I think a third possible approach would be to have a dependency task
> which removes out of date files. Javac would then recompile all necessary
> files. This completely decouples the dependency analysis and action from the
> Javac task. It could presumably be used to specify arbitrary dependencies.
I also have to agree with Peter, this is a -1 for me.
This job is really the compilers. If the compiler kept the parse tree
around then it could use the tree to determine what to incrementally
build.
I had a home grown Imake system which included dependencies and it
would invoke a javac for each indivual file that needed rebuilding.
Besides being a manual process (having to hand craft the imake files)
and being slow (30-45 minute build) it was easier to do as Peter
suggests and recompile the entire source in one go (a less than 5
minute build).
Most of the time you know the dependencies and can let ant check for
out of date files. If you have suspicions then do a clean and
rebuild.
You could always componentize the project so that you depend upon jar
files and thus you only need to rebuild your component which is much
faster.
Barrie
--
Barrie Treloar
____________________________________________________________________
Barrie Treloar Phone: +61 8 8303 3300
Senior Analyst/Programmer Fax: +61 8 8303 4403
Electronic Commerce Division Email: barrie@camtech.com.au
Camtech (SA) Pty Ltd http://www.camtech.com.au
--- Level 8, 10 Pulteney Street, Adelaide SA 5000, Australia. ---
____________________________________________________________________
RE: Incremental Compilation and ant
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Arun,
There is a solution. It involves analyzing the dependencies between classes
to determine which files need to be recompiled. There have been two
proposals in the past which have sought to address this issue. I think there
are three ways to go
1. Add the dependency analysis to Javac and perhaps a switch to decide
whether to use it or not. This has been proposed by Vitaly Stulsky. I think
we still need to whole source code for this proposal.
2. Add a separate dependency task which generates a dependency file. Javac
would use that file to determine which files would need to be recompiled. I
proposed a patch for this approach. It decouples the dependency analysis
from the javac task
3. I think a third possible approach would be to have a dependency task
which removes out of date files. Javac would then recompile all necessary
files. This completely decouples the dependency analysis and action from the
Javac task. It could presumably be used to specify arbitrary dependencies.
I would like to have some discussion on this list about which approach, if
any, we should adopt for this issue. Class file analysis, to extract
dependencies, is not trivial and increases the amount of code in Ant quite a
bit. People may also want to consider source file analysis. Personally I
think class file analysis is both simpler and sufficient.
Conor
--
Conor MacNeill
conor@cortexebusiness.com.au
Cortex eBusiness
http://www.cortexebusiness.com.au
> -----Original Message-----
> From: Arun Katkere [mailto:katkere@praja.com]
> Sent: Friday, 21 July 2000 10:11
> To: ant-dev@jakarta.apache.org
> Subject: Incremental Compilation and ant
>
>
> Javac task filters the list of input source files to only those that are
> newer than corresponding .class files. Which is great. But, not all files
> that need to be recompiled are always recompiled. For instance,
> if we change
> a method signature of a base class, all subclasses are not automatically
> recompiled, creating an inconsistency.
>
> Is there are solution for this problem (other than deleting the
> entire class
> tree)?
>
> -arun
>