]>
Commit | Line | Data |
---|---|---|
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 | 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 | <build>/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/ |