* HACKING: Updated for hacking classpath in libgcj.
authorTom Tromey <tromey@redhat.com>
Sun, 21 Aug 2005 23:24:58 +0000 (23:24 +0000)
committerTom Tromey <tromey@gcc.gnu.org>
Sun, 21 Aug 2005 23:24:58 +0000 (23:24 +0000)
From-SVN: r103324

libjava/ChangeLog
libjava/HACKING

index e3c9a6d1959687b036bddef53b69bd3581f6b86c..4adaf585aab8a6e552544b3d6216e9ed6229ad0a 100644 (file)
@@ -1,3 +1,7 @@
+2005-08-21  Tom Tromey  <tromey@redhat.com>
+
+       * HACKING: Updated for hacking classpath in libgcj.
+
 2005-08-20  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>
 
        PR libgcj/21692
index 410b1cc59e6399b033197a5353cb101d7974cb9e..649a161f2ff827b28bf0cf9f5d9345a8700bdc94 100644 (file)
@@ -60,6 +60,30 @@ However, there are two (known) exceptions to this rule:
 
 --
 
+You can develop in a GCC tree using a CVS checkout of Classpath, most
+of the time.  (The exceptions are when an incompatible change has been
+made in Classpath and some core part of libgcj has not yet been
+updated.)
+
+The way to set this up is very similar to importing a new version of
+Classpath into the libgcj tree.  In your working tree:
+
+* cd gcc/libjava; rm -rf classpath
+* cvs co classpath
+* cd classpath
+  Now run the auto tools as specified in the import process; then
+  cd ..
+* Run 'scripts/makemake.tcl > sources.am' in the source tree
+* Run automake for libgcj
+
+Now you should be ready to go.
+
+If you are working in a tree like this, you must remember to run
+makemake.tcl and automake whenever you update your embedded classpath
+tree.
+
+--
+
 If you add a class to java.lang, java.io, or java.util
 (including sub-packages, like java.lang.ref).