mirror of git://gcc.gnu.org/git/gcc.git
				
				
				
			
		
			
				
	
	
		
			68 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
			
		
		
	
	
			68 lines
		
	
	
		
			2.8 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
| 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 check in the fix to Classpath.  For small changes
 | |
| it may be easier to send a patch to the classpath mailinglist.  For
 | |
| large changes, if you have direct write access to the libgcj tree,
 | |
| then you will also need to get a Classpath account and do the work
 | |
| yourself.
 | |
| <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 (don't 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!
 | |
| 
 | |
| 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/
 | |
| 
 |