ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <Jesse.Gl...@netbeans.com>
Subject Re: Incremental Compilation and ant
Date Fri, 21 Jul 2000 19:26:09 GMT
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   <mailto:Jesse.Glick@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Mime
View raw message