X-Git-Url: http://git.sourceforge.jp/view?a=blobdiff_plain;ds=sidebyside;f=libjava%2FHACKING;h=75bc63b35e7fcf84af4a991b9c4a94232d17f765;hb=f6ce89d9d29bb4da6d0959cbf938fa5aff662fbe;hp=6ea549daef9e1e6f8418668e564cf3ecd896a8ab;hpb=f52859eafaac404d3e0089c3f8b11795f2f2193d;p=pf3gnuchains%2Fgcc-fork.git diff --git a/libjava/HACKING b/libjava/HACKING index 6ea549daef9..75bc63b35e7 100644 --- a/libjava/HACKING +++ b/libjava/HACKING @@ -7,48 +7,174 @@ 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. - -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. - - - -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 plan to modify a .java file, you will need to configure with +--enable-java-maintainer-mode. In order to make this work properly, +you will need to have 'ecj1' and 'gjavah' executables in your PATH at +build time. + +One way to do this is to download ecj.jar (see contrib/download_ecj) +and write a simple wrapper script like: + + #! /bin/sh + gij -cp /home/tromey/gnu/Generics/trunk/ecj.jar \ + org.eclipse.jdt.internal.compiler.batch.GCCMain \ + ${1+"$@"} + +For gjavah, you can make a tools.zip from the classes in +classpath/lib/tools/ and write a gjavah script like: + + #! /bin/sh + dir=/home/tromey/gnu/Generics/Gcjh + gij -cp $dir/tools.zip \ + gnu.classpath.tools.javah.Main \ + ${1+"$@"} + +Another way to get a version of gjavah is to first do a +non-maintainer-mode build and use the newly installed gjavah. + +-- + +To regenerate libjava/configure, first run aclocal passing the flags +found near the top of Makefile.am, then autoconf. H. J. Lu writes that +this can be done using these commands: + + cd libjava && + rm -f aclocal.m4 && + ACFLAGS=$(grep "^ACLOCAL_AMFLAGS" Makefile.in | sed -e "s/ACLOCAL_AMFLAGS[ \t ]*=//") && + aclocal-1.9 $ACFLAGS && + rm -f configure && + autoconf-2.59 && + rm -fr autom4te.cache + +See the GCC documentation which auto* versions to use. + +-- + +libgcj uses GNU Classpath as an upstream provider. Snapshots of +Classpath are imported into the libgcj source tree. Some classes are +overridden by local versions; these files still appear in the libgcj +tree. + +To import a new release: + +- Check out a classpath snapshot or take a release tar.gz file. + I use 'cvs export' for this. Make a tag to ensure future hackers + know exactly what revision was checked out; tags are of the form + 'libgcj-import-DATE' (when using a tagged checkout do: + - ./autogen.sh && ./configure && make dist + to get a proper .tar.gz for importing below). +- Get a svn checkout of + svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath + this contains "pure" GNU Classpath inside the GCC tree. +- Clean it up and get the files from a new version: + - find classpath -type f | grep -v /\.svn | grep -v /\.cvs | xargs rm + - tar zxf classpath-x.tar.gz + - cp -r classpath-x/* classpath +- Add/Remove files: + - svn status classpath | grep ^\! | cut -c8- | xargs svn remove + - svn status classpath | grep ^\? | cut -c8- | xargs svn add +- If there are any empty directories now they can be removed. You can find + candidates (dirs with files removed) with: + - for i in `svn status classpath | grep ^D | cut -c8-`; \ + do ls -d `dirname $i`; done | uniq +- Update vendor branch + - svn commit classpath +- Note the new revision number (Xrev) +- Get a fresh svn trunk checkout and cd gcc/libjava +- Merge the changes between classpath versions into the trunk. + svn merge -rXrev-1:Xrev \ + svn+ssh://gcc.gnu.org/svn/gcc/branches/CLASSPATH/libjava/classpath \ + classpath +- Resolve any conflicts pointed out by svn status classpath | grep ^C + - Makefile.in files will be regenerated in the next step. + - Other files should have a "GCJ LOCAL" comment, and/or are mentioned + in the classpath/ChangeLog.gcj file. + (Don't forget to svn resolved files.) +- Use auto* to create configure, Makefile.in, etc + Make sure you have Automake 1.9.6 installed. Exactly that version! + You have to make sure to use the gcc libtool.m4 and gcc lt* scripts + cd .../classpath + cp ../../lt* . + cp ../../config.sub ../../config.guess . + aclocal -I m4 -I ../.. -I ../../config + autoconf + autoheader + automake + rm -rf autom4te.cache + cd .. + scripts/makemake.tcl > sources.am + automake +- Remove the generated class and header files: + find classpath -name '*.class' | xargs -r rm -f + find gnu java javax org sun -name '*.h' \ + | xargs -r grep -Fl 'DO NOT EDIT THIS FILE - it is machine generated' \ + | xargs -r rm -f +- Build, fix, till everything works. + Be sure to build all peers (--enable-java-awt=gtk,xlib,qt + --enable-gconf-peer --enable-gstreamer-peer) + Be sure to update gnu/classpath/Configuration.java to reflect + the new version + Possibly update the gcj/javaprims.h file with scripts/classes.pl + (See below, it can only be done after the first source->bytecode + pass has finished.) + You will need to configure with --enable-java-maintainer-mode and you + will need to update the .class files and generated CNI header files in + your working tree +- Add/Remove newly generated files: + - svn status classpath | grep '^\!.*\.class$' | cut -c8- | xargs svn remove + - svn status classpath | grep '^\?' | cut -c8- | xargs svn add + - svn status gnu java javax org sun | grep '^\!.*\.h$' | cut -c8- | xargs svn remove + - svn status gnu java javax org sun | grep '^\?' | cut -c8- | xargs svn add + +Over time we plan to remove as many of the remaining divergences as +possible. + +File additions and deletions require running scripts/makemake.tcl +before running automake. + +-- + +In general you should not make any changes in the classpath/ +directory. Changes here should come via imports from upstream. +However, there are three (known) exceptions to this rule: + +* In an emergency, such as a bootstrap breakage, it is ok to commit a + patch provided that the problem is resolved (by fixing a compiler + bug or fixing the Classpath bug upstream) somehow and the resolution + is later checked in (erasing the local diff). + +* On a release branch to fix a bug, where a full-scale import of + Classpath is not advisable. + +* We maintain a fair number of divergences in the build system. + This is a pain but they don't seem suitable for upstream. -- -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): +You can develop in a GCC tree using a CVS checkout of Classpath, most +of the time. (The exceptions are when an incompatible change has been +made in Classpath and some core part of libgcj has not yet been +updated.) + +The way to set this up is very similar to importing a new version of +Classpath into the libgcj tree. In your working tree: + +* cd gcc/libjava; rm -rf classpath +* cvs co classpath +* cd classpath + Now run the auto tools as specified in the import process; then + cd .. +* Run 'scripts/makemake.tcl > sources.am' in the source tree +* Run automake for libgcj -> 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 ;-) +Now you should be ready to go. - +If you are working in a tree like this, you must remember to run +makemake.tcl and automake whenever you update your embedded classpath +tree. -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). @@ -57,11 +183,7 @@ If you add a class to java.lang, java.io, or java.util * 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/ - +* Then insert the output of `perl scripts/classes.pl' into the file + at that point. This must be run from the build tree, in + /classpath/lib; it uses the .class file name to determine + what to print.