From 817752f8938108eab2f95dc93336291f88a501e6 Mon Sep 17 00:00:00 2001 From: tromey Date: Wed, 10 Jan 2007 23:44:46 +0000 Subject: [PATCH] * HACKING: Various updates. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@120653 138bc75d-0d04-0410-961f-82ee72b054a4 --- libjava/ChangeLog | 4 ++++ libjava/HACKING | 37 +++++++++++++++++++++++++++++++------ 2 files changed, 35 insertions(+), 6 deletions(-) diff --git a/libjava/ChangeLog b/libjava/ChangeLog index e3393ed..05b6225 100644 --- a/libjava/ChangeLog +++ b/libjava/ChangeLog @@ -1,5 +1,9 @@ 2007-01-10 Tom Tromey + * HACKING: Various updates. + +2007-01-10 Tom Tromey + * java/lang/natDouble.cc (toString): Added parens. * gnu/gcj/io/shs.h (PROTO): Define. * link.cc (resolve_pool_entry): Added missing braces. diff --git a/libjava/HACKING b/libjava/HACKING index 3c07e5a..f32a3a5 100644 --- a/libjava/HACKING +++ b/libjava/HACKING @@ -7,6 +7,33 @@ explained in this HACKING file. Please add them if you discover them :) -- +If you plan to modify a .java file, you will need to configure with +--enable-java-maintainer-mode. In order to make this work properly, +you will need to have 'ecj1' and 'gjavah' executables in your PATH at +build time. + +One way to do this is to download ecj.jar (see contrib/download_ecj) +and write a simple wrapper script like: + + #! /bin/sh + gij -cp /home/tromey/gnu/Generics/trunk/ecj.jar \ + org.eclipse.jdt.internal.compiler.batch.GCCMain \ + ${1+"$@"} + +For gjavah, you can make a tools.zip from the classes in +classpath/lib/tools/ and write a gjavah script like: + + #! /bin/sh + dir=/home/tromey/gnu/Generics/Gcjh + gij -cp $dir/tools.zip \ + gnu.classpath.tools.javah.Main \ + ${1+"$@"} + +Another way to get a version of gjavah is to first do a +non-maintainer-mode build and use the newly installed gjavah. + +-- + libgcj uses GNU Classpath as an upstream provider. Snapshots of Classpath are imported into the libgcj source tree. Some classes are overridden by local versions; these files still appear in the libgcj @@ -81,7 +108,7 @@ before running automake. In general you should not make any changes in the classpath/ directory. Changes here should come via imports from upstream. -However, there are two (known) exceptions to this rule: +However, there are three (known) exceptions to this rule: * In an emergency, such as a bootstrap breakage, it is ok to commit a patch provided that the problem is resolved (by fixing a compiler @@ -91,6 +118,9 @@ However, there are two (known) exceptions to this rule: * On a release branch to fix a bug, where a full-scale import of Classpath is not advisable. +* We maintain a fair number of divergences in the build system. + This is a pain but they don't seem suitable for upstream. + -- You can develop in a GCC tree using a CVS checkout of Classpath, most @@ -129,8 +159,3 @@ If you add a class to java.lang, java.io, or java.util at that point. This must be run from the build tree, in /classpath/lib; it uses the .class file name to determine what to print. - -If you're generating a patch there is a program you can get to do an -offline `cvs add' (it will fake an `add' if you don't have write -permission yet). Then you can use `cvs diff -N' to generate the -patch. See http://www.red-bean.com/cvsutils/ -- 2.7.4