2001-02-17 15:24:41 +01:00
|
|
|
Things libgcj hackers should know
|
|
|
|
|
---------------------------------
|
|
|
|
|
|
|
|
|
|
If you want to hack on the libgcj files you need to be aware of the
|
|
|
|
|
following things. There are probably lots of other things that should be
|
|
|
|
|
explained in this HACKING file. Please add them if you discover them :)
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
A lot of the standard library files come from the GNU Classpath project.
|
|
|
|
|
<http://www.gnu.org/software/classpath/>
|
|
|
|
|
The libgcj and Classpath project have officially merged, but the merge
|
|
|
|
|
is not yet complete. Our eventual goal is for Classpath to be an upstream
|
|
|
|
|
source provider for libgcj, however it will be some time before this becomes
|
|
|
|
|
reality: libgcj and Classpath have different implementations of many core
|
|
|
|
|
java classes. In order to merge them, we need to select the best (most
|
|
|
|
|
efficient, cleanest) implementation of each method/class/package, resolve
|
|
|
|
|
any conflicts created by the merge, and test the final result.
|
|
|
|
|
|
|
|
|
|
The merged files can be recognized by the standard Classpath copyright
|
|
|
|
|
comments at the top of the file. If you make changes to these files then
|
|
|
|
|
you should also send a patch to the classpath mailinglist.
|
|
|
|
|
<http://mail.gnu.org/mailman/listinfo/classpath/>
|
|
|
|
|
<mailto:classpath@gnu.org>
|
|
|
|
|
|
|
|
|
|
If you merge a libgcj class with a classpath class then you must update the
|
|
|
|
|
copyright notice at the top of the file so others can see that this is a
|
|
|
|
|
shared libgcj/classpath file.
|
|
|
|
|
|
|
|
|
|
--
|
|
|
|
|
|
|
|
|
|
If you need to add new java files to libgcj then you have to edit the
|
|
|
|
|
Makefile.am file in the top (libjava) directory. And run automake.
|
|
|
|
|
But note the following (thanks to Bryce McKinlay):
|
|
|
|
|
|
|
|
|
|
> Do you know the magic dance I have to do when adding files to Makefile.am
|
|
|
|
|
> so they will appear in Makefile.in and finally in the user generated
|
|
|
|
|
> Makefile?
|
|
|
|
|
Yup, you need the magic libgcj automake ;-)
|
|
|
|
|
|
|
|
|
|
<ftp://ftp.freesoftware.com/.0/sourceware/java/automake-gcj-1.4.tar.gz>
|
|
|
|
|
|
|
|
|
|
Install that (dont worry, it should still work for other projects), add your
|
|
|
|
|
files to the Makefile.am, then just type "automake" and it will regenerate the
|
|
|
|
|
Makefile.in. Easy!
|
|
|
|
|
|
2001-07-29 12:05:08 +02:00
|
|
|
Tom Tromey adds:
|
|
|
|
|
If you add a class to java.lang, java.io, or java.util
|
|
|
|
|
(including sub-packages, like java.lang.ref).
|
|
|
|
|
|
|
|
|
|
* Edit gcj/javaprims.h
|
|
|
|
|
|
|
|
|
|
* Go to the `namespace java' line, and delete that entire block (the
|
|
|
|
|
entire contents of the namespace)
|
|
|
|
|
|
|
|
|
|
* Then insert the output of `perl ../scripts/classes.pl' into the file
|
|
|
|
|
at that point.
|
|
|
|
|
|
|
|
|
|
If you're generating a patch there is a program you can get to do an
|
|
|
|
|
offline `cvs add' (it will fake an `add' if you don't have write
|
|
|
|
|
permission yet). Then you can use `cvs diff -N' to generate the
|
|
|
|
|
patch. See http://www.red-bean.com/cvsutils/
|
|
|
|
|
|
