java/1450: -M generates incorrect dependancies for .class files

java/1450: -M generates incorrect dependancies for .class files

[Mike, Moreton]

>Number:         1450
>Category:       java
>Synopsis:       -M generates incorrect dependancies for .class files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    tromey
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 20 12:20:04 PST 2000
>Closed-Date:    Sun Jun 18 23:42:35 PDT 2000
>Last-Modified:  Sun Jun 18 23:50:00 PDT 2000
>Originator:     Mike Moreton
>Release:        gcc version 2.95.1 19990816 (release)
>Organization:
>Environment:

>Description:
If a java file is dependant on a class that has a .class
file, then the -M and -MM options generate a dependancy to
the .java file rather than the .class file.

This was obviously deliberate, but it can mess up make, as
a class's ".class" file can change without the .java file
changing.  (e.g. if this class is a sub-class of another
class, and that class changes)  If this happens, make won't 
spot the change, and hence the original java file won't get
recompiled, and your link will fail.
>How-To-Repeat:
You need three java files:

A.java:
public class A {}

B.java:
public class B extends A {}

C.java:
public class C {
	public someMethod() {
		B myB = new B();
	}
}

run gcj -C B.java, then gcj -M C.java and you'll get a 
dependancy on B.java not B.class

If you then change the name of a method in A that is called
from C, B.class will get recompiled, but because C.o does
not depend on B.class, it won't get recompiled.
>Fix:
In jcf-io.c function open_class, replace the lines

      if (dep_name != NULL)
        jcf_dependency_add_file (dep_name, 0);

with
        jcf_dependency_add_file (filename, 0);

>Release-Note:

>Audit-Trail:

Formerly PR gcj/70

Responsible-Changed-From-To: apbianco->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Thu Nov  4 21:37:58 1999
Responsible-Changed-Why:
    The dependency-tracking code is mine, more or less.
State-Changed-From-To: open->feedback
State-Changed-By: tromey
State-Changed-When: Thu Nov  4 21:37:58 1999
State-Changed-Why:
    I don't fully understand your example.
    I followed your example.  Then I tried compiling C.java:
    
    creche. gcj -M C.java 
    C.o : ./A.java ./B.java /x1/egcs/install/share/libgcj.zip C.java
    
    
    I think the dependency on A.java is telling.  C depends on
    A because the compilation of C causes B to be read,
    which in turn causes A to be read.
    So I don't see how your case could occur.
    
    I don't doubt there is a problem here.  It's just that
    I don't understand what it is, and unfortunately your
    example doesn't seem to show it.  Can you change your
    example to show the problem?

From: tromey@cygnus.com
To: Mike@sourceware.cygnus.com, Moreton@sourceware.cygnus.com,
  apbianco@cygnus.com, java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: gcj/70
Date: 5 Nov 1999 05:37:58 -0000

 Synopsis: -M generates incorrect dependancies for .class files
 
 Responsible-Changed-From-To: apbianco->tromey
 Responsible-Changed-By: tromey
 Responsible-Changed-When: Thu Nov  4 21:37:58 1999
 Responsible-Changed-Why:
     The dependency-tracking code is mine, more or less.
 State-Changed-From-To: open->feedback
 State-Changed-By: tromey
 State-Changed-When: Thu Nov  4 21:37:58 1999
 State-Changed-Why:
     I don't fully understand your example.
     I followed your example.  Then I tried compiling C.java:
     
     creche. gcj -M C.java 
     C.o : ./A.java ./B.java /x1/egcs/install/share/libgcj.zip C.java
     
     
     I think the dependency on A.java is telling.  C depends on
     A because the compilation of C causes B to be read,
     which in turn causes A to be read.
     So I don't see how your case could occur.
     
     I don't doubt there is a problem here.  It's just that
     I don't understand what it is, and unfortunately your
     example doesn't seem to show it.  Can you change your
     example to show the problem?
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&database=java&pr=70
State-Changed-From-To: feedback->closed
State-Changed-By: bryce
State-Changed-When: Sun Jun 18 23:42:35 2000
State-Changed-Why:
    - This is an ancient PR,
    - we havn't heard back from the reporter,
    - and I agree with Tom that there isn't a problem here:
    
    $ gcj -C B.java
    $ rm B.java
    $ gcj -M C.java 
    C.o : C.java /usr/local/gcc/share/libgcj.zip ./B.class ./A.java
    
    Changes to B's superclass, A, will still cause a rebuild of C
    because gcj -M also reports the dependency on A.java.

From: bryce@albatross.co.nz
To: Moreton@sourceware.cygnus.com, Mike@sourceware.cygnus.com,
  java-gnats@sourceware.cygnus.com, tromey@cygnus.com
Cc:  
Subject: Re: gcj/70
Date: 19 Jun 2000 06:42:35 -0000

 Synopsis: -M generates incorrect dependancies for .class files
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bryce
 State-Changed-When: Sun Jun 18 23:42:35 2000
 State-Changed-Why:
     - This is an ancient PR,
     - we havn't heard back from the reporter,
     - and I agree with Tom that there isn't a problem here:
     
     $ gcj -C B.java
     $ rm B.java
     $ gcj -M C.java 
     C.o : C.java /usr/local/gcc/share/libgcj.zip ./B.class ./A.java
     
     Changes to B's superclass, A, will still cause a rebuild of C
     because gcj -M also reports the dependency on A.java.
 
 http://sourceware.cygnus.com/cgi-bin/gnatsweb.pl?cmd=view&pr=70&database=java
>Unformatted: