| 1 |
14 |
jlechner |
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 |
|
|
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
|
| 41 |
|
|
|
| 42 |
|
|
Over time we plan to remove as many of the remaining divergences as
|
| 43 |
|
|
possible.
|
| 44 |
|
|
|
| 45 |
|
|
File additions and deletions require running scripts/makemake.tcl
|
| 46 |
|
|
before running automake.
|
| 47 |
|
|
|
| 48 |
|
|
--
|
| 49 |
|
|
|
| 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:
|
| 53 |
|
|
|
| 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).
|
| 58 |
|
|
|
| 59 |
|
|
* On a release branch to fix a bug, where a full-scale import of
|
| 60 |
|
|
Classpath is not advisable.
|
| 61 |
|
|
|
| 62 |
|
|
--
|
| 63 |
|
|
|
| 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.)
|
| 68 |
|
|
|
| 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:
|
| 71 |
|
|
|
| 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
|
| 79 |
|
|
|
| 80 |
|
|
Now you should be ready to go.
|
| 81 |
|
|
|
| 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.
|
| 85 |
|
|
|
| 86 |
|
|
--
|
| 87 |
|
|
|
| 88 |
|
|
If you add a class to java.lang, java.io, or java.util
|
| 89 |
|
|
(including sub-packages, like java.lang.ref).
|
| 90 |
|
|
|
| 91 |
|
|
* Edit gcj/javaprims.h
|
| 92 |
|
|
|
| 93 |
|
|
* Go to the `namespace java' line, and delete that entire block (the
|
| 94 |
|
|
entire contents of the namespace)
|
| 95 |
|
|
|
| 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 |
|
|
/classpath/lib; it uses the .class file name to determine
|
| 99 |
|
|
what to print.
|
| 100 |
|
|
|
| 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/
|
