Re: GNU automake and Java, inconsistency after changes

[Dalibor Topic]

Hallo Roman,

address@hidden wrote:
> Hello,

> Assume class A in A.java has a function "void f(int i)" and B is
> calling that properly. Now you "make" the program and everything is
> fine. Then you edit A.java and change "void f(int i)" to "void f()" and
> do one more "make". It'll compile and you do *not* get an error
> reported, because in the compile rule for Java (as of automake 1.8.2)
> ...

AFAIK, automake can not/does not do dependency tracking for java 
sources. There is an interesting GPLd program out there, called JavaDeps 
(especially the lucent version seems to have some interesting 
improvements), that can be used to generate Makefile rules for 
dependencies. It's still not good enough for what I'd need for kaffe, 
but it seems to be a step in the right direction.

> ... there stands a "$?" as the list of the files to be recompiled,
> which would only be A.java. Because javac is smart enough not to
> recompile everything, it would probably bee better to recompile all
> Java sources (replace "$?" with "$(java_JAVA)") to catch that error,
> because when recompiling parsing both files, javac will detect the change
> in A.java and recompile both files, detecting the inconsistency.

Sun's Javac may be smart enough to do that, other java compilers (gcj, 
kjc) avoid that greedy approach to compile everything in one's reach and 
do exactly as they are being told.

In my opinion dependency management doesn't belong in the compiler, it 
belongs into a make tool ;)

> I do not know how performant that chhange would be with really large
> Java subdirectories.

For compilers that can do a lot of optimizations to native code (gcj): 
very bad, I assume. When you have a few thousand source files in your 
class library, you want to avoid recompiling them all for a few hours, 
just because someone fixed a spelling mistake. ;)

cheers,
dalibor topic