Re: [Patch] Java: Add heap dump and analyze support.

[David Daney <ddaney at avtrex dot com>]

Tom Tromey wrote:
> > > > > > "David" == David Daney <ddaney@avtrex.com> writes:
>
> > > I wonder if we could fix this by putting the new tool code into
> > > standard.omit, and then compile it separately using a special rule of
> > > some kind, with a classpath pointing to the tools zip.
>
> David> Ok, I added some rules to classpath/lib/Makefile.am, that parallel the
> David> special libgcj rules, to build gcj tools with a different classpath.
> David> To build more packages this way (i.e. gcj_dbtool), it should be as
> David> simple as adding the package name to the list in libjava's
> David> configure.ac. There will no longer be any excuses to prevent us from
> David> converting gcj_dbtool to use the getopt things.
>
> David> OK to commit if no regressions?
>
> I was hoping for 2 things, which I didn't communicate well.
>
> One is, no changes to libjava/classpath/.  But I realize now that this
> is too hard.
>
> The other is, not adding the tools classes to AM_GCJFLAGS.

This shouldn't matter because the tools classes are not included in the 
java -> class compilation classpath.  If there are problems, they will 
show up in this step.

> Instead of adding a new script in classpath/lib, would it be posssible
> to build the new tool code in classpath/tools/Makefile?  Then the new
> tool could be built in libjava/Makefile.am following the recipe for
> all the other classpath tools.

(Almost) anything is possible.  If I did it that way, there would be a 
great asymmetry in that gcj_dbtool is not built that way.

David Daney