Re: javac issues

[Vaclav Barta]

Michael Cook wrote:
> 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).
OK, that makes sense - every existing dependency is found, and 
there shouldn't be that many false positives... But did your
script handle Unicode characters in class names? Here's an excuse
to exercise Perl Unicode support... :-)
As I come to think about it, do we actually need to parse the
whole .class file? Isn't the list of used class names already in
some kind of a symbol table? I must read that JVM spec one of
these days...

> 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
automake AFAIK does that when used with gcc.

> tell cons, "here's a group of source files; if any of these
> files is out of date, invoke this here command indicating which
...
> 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.
Wow! :-)

        Bye
                Vasek