2005-12-16 Andreas Krebbel <krebbel1@de.ibm.com>
[official-gcc.git] / libjava / HACKING
blob7a9b69d6ff1d9d07ca24b426d469cdc3bd9065f1
1 Things libgcj hackers should know
2 ---------------------------------
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 :)
8 --
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.
15 To import a new release:
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   cp ../../config.sub ../../config.guess .
26   aclocal -I m4 -I ../..
27   autoconf
28   autoheader
29   automake
30   rm -rf autom4te.cache
31 - Test everything first.  The simplest way to do this is by overlaying
32   the checked out classpath on your gcc tree and then doing a build.
33 - Use 'cvs import' to import.  The vendor tag is 'CLASSPATH'.  For the
34   release tag, if this is a released classpath version, use something
35   like 'classpath-import-VERSION'; otherwise something like
36   'classpath-import-DATE'.
37   Be sure to use -ko and -I\!
38 - Remove any files that were deleted in Classpath
39 - Run 'scripts/makemake.tcl > sources.am' in the source tree
40 - Run automake for libgcj
42 Over time we plan to remove as many of the remaining divergences as
43 possible.
45 File additions and deletions require running scripts/makemake.tcl
46 before running automake.
50 In general you should not make any changes in the classpath/
51 directory.  Changes here should come via imports from upstream.
52 However, there are two (known) exceptions to this rule:
54 * In an emergency, such as a bootstrap breakage, it is ok to commit a
55   patch provided that the problem is resolved (by fixing a compiler
56   bug or fixing the Classpath bug upstream) somehow and the resolution
57   is later checked in (erasing the local diff).
59 * On a release branch to fix a bug, where a full-scale import of
60   Classpath is not advisable.
64 You can develop in a GCC tree using a CVS checkout of Classpath, most
65 of the time.  (The exceptions are when an incompatible change has been
66 made in Classpath and some core part of libgcj has not yet been
67 updated.)
69 The way to set this up is very similar to importing a new version of
70 Classpath into the libgcj tree.  In your working tree:
72 * cd gcc/libjava; rm -rf classpath
73 * cvs co classpath
74 * cd classpath
75   Now run the auto tools as specified in the import process; then
76   cd ..
77 * Run 'scripts/makemake.tcl > sources.am' in the source tree
78 * Run automake for libgcj
80 Now you should be ready to go.
82 If you are working in a tree like this, you must remember to run
83 makemake.tcl and automake whenever you update your embedded classpath
84 tree.
88 If you add a class to java.lang, java.io, or java.util
89 (including sub-packages, like java.lang.ref).
91 * Edit gcj/javaprims.h
93 * Go to the `namespace java' line, and delete that entire block (the   
94   entire contents of the namespace)
96 * Then insert the output of `perl scripts/classes.pl' into the file
97   at that point.  This must be run from the build tree, in
98   <build>/classpath/lib; it uses the .class file name to determine
99   what to print.
101 If you're generating a patch there is a program you can get to do an
102 offline `cvs add' (it will fake an `add' if you don't have write
103 permission yet).  Then you can use `cvs diff -N' to generate the
104 patch.  See http://www.red-bean.com/cvsutils/