X-Git-Url: http://git.sourceforge.jp/view?a=blobdiff_plain;f=libjava%2FHACKING;h=3e99bed0e5a82deaa1cd7f57c8bd8d3083d6695f;hb=553c4d0b518bc21d7f6cd7695428c4d2a9f28e51;hp=df74b06414e7cb6442c9272f01b4f44d534ec0cb;hpb=a63c2657c94913d72b3cd388730d61edcb09fc69;p=pf3gnuchains%2Fgcc-fork.git diff --git a/libjava/HACKING b/libjava/HACKING index df74b06414e..3e99bed0e5a 100644 --- a/libjava/HACKING +++ b/libjava/HACKING @@ -7,6 +7,49 @@ explained in this HACKING file. Please add them if you discover them :) -- +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.11 $ACFLAGS && + rm -f configure && + autoconf-2.64 && + 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 @@ -14,26 +57,75 @@ tree. To import a new release: -- Check out a classpath snapshot +- 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.11.1 installed. Exactly that version! You have to make sure to use the gcc libtool.m4 and gcc lt* scripts cd .../classpath cp ../../lt* . - aclocal -I m4 -I ../.. + cp ../../config.sub ../../config.guess . + aclocal -I m4 -I ../.. -I ../../config autoconf autoheader automake rm -rf autom4te.cache -- Test everything first. The simplest way to do this is by overlaying - the checked out classpath on your gcc tree and then doing a build. -- Use 'cvs import' to import. The vendor tag is 'CLASSPATH'. For the - release tag, if this is a released classpath version, use something - like 'classpath-import-VERSION'; otherwise something like - 'classpath-import-DATE'. - Be sure to use -ko and -I\! -- Remove any files that were deleted in Classpath -- Run 'scripts/makemake.tcl > sources.am' in the source tree -- Run automake for libgcj + 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 build gjdoc (--enable-gjdoc). + 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. @@ -41,11 +133,48 @@ 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. +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 + +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. + +-- If you add a class to java.lang, java.io, or java.util (including sub-packages, like java.lang.ref). @@ -56,12 +185,6 @@ If you add a class to java.lang, java.io, or java.util entire contents of the namespace) * 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 + at that point. This must be run from the source tree, in + libjava/classpath/lib; it uses the .class file name to determine what to print. - -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/ -