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 or take a release tar.gz file.
  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' (when using a tagged checkout do:
  21   - ./autogen.sh && ./configure && make dist
  22   to get a proper .tar.gz for importing below).
  23 - Get a svn checkout of
  24   svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath
  25   this contains "pure" GNU Classpath inside the GCC tree.
  26 - Clean it up and get the files from a new version:
  27   - find classpath -type f | grep -v /\.svn | grep -v /\.cvs | xargs rm
  28   - tar zxf classpath-x.tar.gz
  29   - cp -r classpath-x/* classpath
  30 - Add/Remove files:
  31   - svn status classpath | grep ^\! | cut -c8- | xargs svn remove
  32   - svn status classpath | grep ^\? | cut -c8- | xargs svn add
  33 - If there are any empty directories now they can be removed. You can find
  34   candidates (dirs with files removed) with:
  35   - for i in `svn status classpath | grep ^D | cut -c8-`; \
  36       do ls -d `dirname $i`; done | uniq
  37 - Update vendor branch
  38   - svn commit classpath
  39 - Note the new revision number (Xrev)
  40 - Get a fresh svn trunk checkout and cd gcc/libjava
  41 - Merge the changes between classpath versions into the trunk.
  42   svn merge -rXrev-1:Xrev \
  43   svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath \
  44   classpath
  45 - Resolve any conflicts pointed out by svn status classpath | grep ^C
  46   - Makefile.in files will be regenerated in the next step.
  47   - Other files should have a "GCJ LOCAL" comment, and/or are mentioned
  48     in the classpath/ChangeLog.gcj file.
  49    (Don't forget to svn resolved files.)
  50 - Use auto* to create configure, Makefile.in, etc
  51   Make sure you have Automake 1.9.6 installed. Exactly that version!
  52   You have to make sure to use the gcc libtool.m4 and gcc lt* scripts
  53   cd .../classpath
  54   cp ../../lt* .
  55   cp ../../config.sub ../../config.guess .
  56   aclocal -I m4 -I ../.. -I ../../config
  57   autoconf
  58   autoheader
  59   automake
  60   rm -rf autom4te.cache
  61   cd ..
  62   scripts/makemake.tcl > sources.am
  63   automake
  64 - Build, fix, till everything works.
  65   Be sure to update gnu/classpath/Configuration.java to reflect
  66     the new version
  67   Possibly update the gcj/javaprims.h file with scripts/classes.pl
  68   (See below, it can only be done after the first source->bytecode
  69    pass has finished.)
  70   You will need to configure with --enable-maintainer-mode and you
  71   will need to update the .class files and generated CNI header files in
  72   your working tree
  73
  74 Over time we plan to remove as many of the remaining divergences as
  75 possible.
  76
  77 File additions and deletions require running scripts/makemake.tcl
  78 before running automake.
  79
  80 --
  81
  82 In general you should not make any changes in the classpath/
  83 directory.  Changes here should come via imports from upstream.
  84 However, there are two (known) exceptions to this rule:
  85
  86 * In an emergency, such as a bootstrap breakage, it is ok to commit a
  87   patch provided that the problem is resolved (by fixing a compiler
  88   bug or fixing the Classpath bug upstream) somehow and the resolution
  89   is later checked in (erasing the local diff).
  90
  91 * On a release branch to fix a bug, where a full-scale import of
  92   Classpath is not advisable.
  93
  94 --
  95
  96 You can develop in a GCC tree using a CVS checkout of Classpath, most
  97 of the time.  (The exceptions are when an incompatible change has been
  98 made in Classpath and some core part of libgcj has not yet been
  99 updated.)
 100
 101 The way to set this up is very similar to importing a new version of
 102 Classpath into the libgcj tree.  In your working tree:
 103
 104 * cd gcc/libjava; rm -rf classpath
 105 * cvs co classpath
 106 * cd classpath
 107   Now run the auto tools as specified in the import process; then
 108   cd ..
 109 * Run 'scripts/makemake.tcl > sources.am' in the source tree
 110 * Run automake for libgcj
 111
 112 Now you should be ready to go.
 113
 114 If you are working in a tree like this, you must remember to run
 115 makemake.tcl and automake whenever you update your embedded classpath
 116 tree.
 117
 118 --
 119
 120 If you add a class to java.lang, java.io, or java.util
 121 (including sub-packages, like java.lang.ref).
 122
 123 * Edit gcj/javaprims.h
 124
 125 * Go to the `namespace java' line, and delete that entire block (the
 126   entire contents of the namespace)
 127
 128 * Then insert the output of `perl scripts/classes.pl' into the file
 129   at that point.  This must be run from the build tree, in
 130   <build>/classpath/lib; it uses the .class file name to determine
 131   what to print.
 132
 133 If you're generating a patch there is a program you can get to do an
 134 offline `cvs add' (it will fake an `add' if you don't have write
 135 permission yet).  Then you can use `cvs diff -N' to generate the
 136 patch.  See http://www.red-bean.com/cvsutils/