]>
Commit | Line | Data |
---|---|---|
a7e96ed4 MW |
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 | A lot of the standard library files come from the GNU Classpath project. | |
11 | <http://www.gnu.org/software/classpath/> | |
12 | The libgcj and Classpath project have officially merged, but the merge | |
13 | is not yet complete. Our eventual goal is for Classpath to be an upstream | |
14 | source provider for libgcj, however it will be some time before this becomes | |
15 | reality: libgcj and Classpath have different implementations of many core | |
16 | java classes. In order to merge them, we need to select the best (most | |
17 | efficient, cleanest) implementation of each method/class/package, resolve | |
18 | any conflicts created by the merge, and test the final result. | |
19 | ||
20 | The merged files can be recognized by the standard Classpath copyright | |
2a2be25e TT |
21 | comments at the top of the file. If you make changes to these files |
22 | then you should also check in the fix to Classpath. For small changes | |
23 | it may be easier to send a patch to the classpath mailinglist. For | |
24 | large changes, if you have direct write access to the libgcj tree, | |
25 | then you will also need to get a Classpath account and do the work | |
26 | yourself. | |
a7e96ed4 MW |
27 | <http://mail.gnu.org/mailman/listinfo/classpath/> |
28 | <mailto:classpath@gnu.org> | |
29 | ||
30 | If you merge a libgcj class with a classpath class then you must update the | |
31 | copyright notice at the top of the file so others can see that this is a | |
32 | shared libgcj/classpath file. | |
33 | ||
34 | -- | |
35 | ||
36 | If you need to add new java files to libgcj then you have to edit the | |
37 | Makefile.am file in the top (libjava) directory. And run automake. | |
38 | But note the following (thanks to Bryce McKinlay): | |
39 | ||
40 | > Do you know the magic dance I have to do when adding files to Makefile.am | |
41 | > so they will appear in Makefile.in and finally in the user generated | |
42 | > Makefile? | |
43 | Yup, you need the magic libgcj automake ;-) | |
44 | ||
e291c8db | 45 | <ftp://sources.redhat.com/pub/java/automake-gcj-1.4.tar.gz> |
a7e96ed4 | 46 | |
18e1f2bd | 47 | Install that (don't worry, it should still work for other projects), add your |
a7e96ed4 MW |
48 | files to the Makefile.am, then just type "automake" and it will regenerate the |
49 | Makefile.in. Easy! | |
50 | ||
7729617c MW |
51 | Tom Tromey adds: |
52 | If you add a class to java.lang, java.io, or java.util | |
53 | (including sub-packages, like java.lang.ref). | |
54 | ||
55 | * Edit gcj/javaprims.h | |
56 | ||
57 | * Go to the `namespace java' line, and delete that entire block (the | |
58 | entire contents of the namespace) | |
59 | ||
60 | * Then insert the output of `perl ../scripts/classes.pl' into the file | |
61 | at that point. | |
62 | ||
63 | If you're generating a patch there is a program you can get to do an | |
64 | offline `cvs add' (it will fake an `add' if you don't have write | |
65 | permission yet). Then you can use `cvs diff -N' to generate the | |
66 | patch. See http://www.red-bean.com/cvsutils/ | |
67 |