libjava/HACKING

   1 Things libgcj hackers should know
   2 ---------------------------------
   3
   4 If you want to hack on the libgcj files you need to be aware of the
   5 following things. There are probably lots of other things that should be
   6 explained in this HACKING file. Please add them if you discover them :)
   7
   8 --
   9
  10 libgcj uses GNU Classpath as an upstream provider.  Snapshots of
  11 Classpath are imported into the libgcj source tree.  Some classes are
  12 overridden by local versions; these files still appear in the libgcj
  13 tree.
  14
  15 To import a new release:
  16
  17 - Check out a classpath snapshot
  18   I use 'cvs export' for this.  Make a tag to ensure future hackers
  19   know exactly what revision was checked out; tags are of the form
  20   'libgcj-import-DATE'.
  21 - Use auto* to create configure, Makefile.in, etc
  22   You have to make sure to use the gcc libtool.m4 and gcc lt* scripts
  23   cd .../classpath
  24   cp ../../lt* .
  25   aclocal -I m4 -I ../..
  26   autoconf
  27   autoheader
  28   automake
  29   rm -rf autom4te.cache
  30 - Test everything first.  The simplest way to do this is by overlaying
  31   the checked out classpath on your gcc tree and then doing a build.
  32 - Use 'cvs import' to import.  The vendor tag is 'CLASSPATH'.  For the
  33   release tag, if this is a released classpath version, use something
  34   like 'classpath-import-VERSION'; otherwise something like
  35   'classpath-import-DATE'.
  36   Be sure to use -ko and -I\!
  37 - Remove any files that were deleted in Classpath
  38 - Run 'scripts/makemake.tcl > sources.am' in the source tree
  39 - Run automake for libgcj
  40
  41 Over time we plan to remove as many of the remaining divergences as
  42 possible.
  43
  44 File additions and deletions require running scripts/makemake.tcl
  45 before running automake.
  46
  47 --
  48
  49 In general you should not make any changes in the classpath/
  50 directory.  Changes here should come via imports from upstream.
  51 However, there are two (known) exceptions to this rule:
  52
  53 * In an emergency, such as a bootstrap breakage, it is ok to commit a
  54   patch provided that the problem is resolved (by fixing a compiler
  55   bug or fixing the Classpath bug upstream) somehow and the resolution
  56   is later checked in (erasing the local diff).
  57
  58 * On a release branch to fix a bug, where a full-scale import of
  59   Classpath is not advisable.
  60
  61 --
  62
  63 If you add a class to java.lang, java.io, or java.util
  64 (including sub-packages, like java.lang.ref).
  65
  66 * Edit gcj/javaprims.h
  67
  68 * Go to the `namespace java' line, and delete that entire block (the
  69   entire contents of the namespace)
  70
  71 * Then insert the output of `perl scripts/classes.pl' into the file
  72   at that point.  This must be run from the build tree, in
  73   <build>/classpath/lib; it uses the .class file name to determine
  74   what to print.
  75
  76 If you're generating a patch there is a program you can get to do an
  77 offline `cvs add' (it will fake an `add' if you don't have write
  78 permission yet).  Then you can use `cvs diff -N' to generate the
  79 patch.  See http://www.red-bean.com/cvsutils/