From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexandre Petit-Bianco To: gcc-announce@gcc.gnu.org Cc: java-announce@sources.redhat.com Subject: Libgcj relocation announce. Date: Sat, 04 Nov 2000 22:34:00 -0000 Message-id: <200011041735.JAA13578@deliverance.cygnus.com> X-SW-Source: 2000/msg00003.html 1) What we intend to do: The libgcj/gcj team plans on moving the source code of the Java run-time environment, called libgcj from its own source tree to Gcc's source tree. We plan to do this by copying over the `,v' files from the libgcj CVS repository to the gcc CVS repository. That will let us preserve our extensive version history. Because of uncleared licensing issues, libgcj has always been made accessible as a separate source tree and Java hackers would first have to build and install the proper compilers (gcj and c++) before configuring and building the sources of their Java runtime. But now that the licensing issues have be cleared, libgcj will be moved to the base of the gcc tree and the Java run-time system will be treated the same way other run-time sources (like libstdc++-v3 or libchill) currently are. This will add four new directories to the source tree: - libjava/, which contains over 1600 files, most of them are Java or C++ files. This is our implementation of a Java run-time, - boehm-gc/, which mostly consists of C files and implements Hans Boehm's conservative garbage collector the Java run-time needs, - libffi/, which contains C and assembly files and is used by the Java interpreter implemented in libjava/, - fastjar/, which contains a GPL'ed archive utility we need in order to create our class file archive. 2) New faces We will be giving write access to the libgcj/gcj repositories to the following persons: bryce:****:9054:65530:Bryce McKinlay:/home/bryce:/bin/bash krab:*****:9057:65530:Kresten Krab Thorup:/home/krab:/bin/bash brads:****:9069:65530:Bradley Schatz:/home/brads:/bin/tcsh hboehm:***:9081:65530:Hans Boehm:/home/hboehm:/bin/tcsh mark:*****:9112:65530:Mark Wielaard:/home/mark:/bin/tcsh rolfwr:***:9116:65530:Rolf Rasmussen:/home/rolfwr:/bin/tcsh Bryce works everywhere libgcj/gcj need to be fixed, Kresten wrote our interpreter. Bradley works on our web pages. Hans helped us with his collector and ported libffi to IA-64. Mark hacks on the core classes, Rolf hacks mostly on AWT classes. 3) How will this change your life? How this will change your life depends on the extent of your interests with Gcc and how you relate to the source tree. - If you have no interested in Java, don't configure the toolchain for Java support and you will never build the Java run-time pieces. - If you are a maintainer of the compiler, especially a C++ maintainer, we encourage you to compile the Java run-time environment as it depends on special and general C++ support to build. It exercises your code in new ways and makes sure that your C++ changes aren't breaking what Java relies on. If you change the infrastructure of the compilers suite, building and testing the Java run-time will let you know if you broke something in the Java front-end. If you are a maintainer of one of the libraries libgcj depends on, like libstdc++-v3, you should also build the Java run-time sometimes. Libgcj features a minimal testsuite that should let you know if something went horribly wrong. More ambitious testing can be done using the Mauve test suite ( http://sources.redhat.com/mauve/ ) 4) How are we trying to make sure that it will work. We're experimenting with a merged tree as we speak. Before we effectively move the sources, we plan on claiming build support for the following platforms: x86/Linux testing Debian current stable and Red Hat distros Alpha/Linux PPC/Linux Most likely LinuxPPC.org Sparc/Solaris 5.x x86/FreeBSD 3.x We will also test a cross compiler; most likely a Linux or Solaris hosted Tx39 toolchain. 5) What do you have to do to make it to work? - Make sure you don't disable building the java compiler when you configure your tree, - There are two libgcj specific configure options you should consider using `--enable-shared' and `enable-threads=posix'. - From the toplevel of your build directory, `make' should build libgcj. See the links below for more details. 6) When We'll proceed when we're ready and when we have addressed people's concerns regarding this operation. We plan on stabilizing the libgcj tree first by disabling its write access and start building on the selected platforms. We will perform adequate testing and then move the repository over, preferably during a quiet day; most likely at the end of a week-end. 7) Post merge management: inquiries, problem reports and contributions After the merge occur, the libgcj/gcj team will respond to inquiries and problem reports. The mailing list for this is `java-discuss', see the mailing lists link below for details. We encourage people to file problem reports into our GNATS database. If you wish to contribute patches, please send them to the `java-patches' list. 8) Libgcj/Gcj resources. The libgcj/gcj web pages are kept in a separate directory. Over time, we plan to merge our web pages into the gcc pages. For now, the libgcj/gcj web pages can be found at: http://sources.redhat.com/java/ Main http://sources.redhat.com/java/mail.html Mailing lists http://sources.redhat.com/java/build-snapshot.html Building libgcj http://sources.redhat.com/java/libgcj-platforms.html Supported platforms http://sources.redhat.com/java/faq.html#3_0 Build FAQs The libgcj/gcj GNATS database: http://sources.redhat.com/cgi-bin/gnatsweb.pl You should use the `libgcj' category. Note that we haven't yet decided how to address our separate Gnats database. We're reluctant to move PRs into the gcc database as that would require renumbering. Suggestions welcome. -- The libgcj/gcj team.