This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Java: Add heap dump and analyze support.
- From: Tom Tromey <tromey at redhat dot com>
- To: David Daney <ddaney at avtrex dot com>
- Cc: Java Patch List <java-patches at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org, "Johannes P. Schmidt" <jschmidt at avtrex dot com>
- Date: 13 Feb 2007 09:16:30 -0700
- Subject: Re: [Patch] Java: Add heap dump and analyze support.
- References: <45AEB57B.5090807@avtrex.com> <m3y7ntld3x.fsf@localhost.localdomain> <45BE8A03.6040101@avtrex.com> <m364adzpe2.fsf@localhost.localdomain> <45D14E4B.6040204@avtrex.com>
- Reply-to: tromey at redhat dot com
>>>>> "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.
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.
Tom