Re: javac issues

[Michael Cook]

Vaclav Barta <address@hidden> writes:

> it is possible to disassemble the .class file with "javap" and
> parse the text output.

a while back, i worked out a gmake-based solution to this javac
problem using this idea of looking inside the .class files.  gmake
would invoke a wrapper script passing the names of all the .java
files.  the script would look for the corresponding .class files,
and would scan them to find out what other classes they seemed to be
using.  using this information, the script would build its own
dependency graph.  the script would then compare the timestamps of
each .class file to its .java file.  each .class file was considered
out of date if:

 - it was missing
 - its modification time was less than its .java file
 - for each other class it used, if that .class file was out of date.

the result of this analysis is a set of .java file names.
that set would be passed to javac.

after javac finished, the script would re-scan all of the .class
files to re-generate the dependency graph.  the script would output
this graph as a makefile.  at the next invocation of gmake, that
makefile would be included and would give gmake the information it
needed to decide whether the script should be invoked again.

this approach seemed to work well enough.  for speed, i used a
heuristic to scan the .class files (i just searched the raw .class
file looking for any byte sequence that looked like a class name
that might correspond to our sources).

so, in short, the basic approach is to have gmake's invocation of a
command be able to output dependency information that feeds into
subsequent gmake invocations.  i expect cons could be coaxed into
using the same solution.

this approach actually seems to be a more general solution to the
problem of building some files from others.  for example, when
compiling a .c file into a .o file, the command might generate not
only the .o file, but also a file indicating what .h files were used
during compliation.  imagine if you could tell cons, "here's a group
of source files; if any of these files is out of date, invoke this
here command indicating which files are out of date.  in return, the
command will indicate which files it has updated and what the
resulting dependency information is."

it seems like all existing rules could be subsumed by this facility.
and then we'd also have the extra power needed to express elegantly
how to handle java source files.

as a bonus, we'd be able to use this facility for C and C++
compilers and other compilers that /can/ be invoked with multiple
source files but generally aren't because it's too difficult for
gmake to understand.

m.