lug-bg: [ANNOUNCE] Libgcj relocation announce. (fwd)

[stefand@xxxxxxxxxxxxxx (Stefan Dragnev)]

Ako niakoi se interesuva ot Java za Linux.

Stefan

---------- Forwarded message ----------
Date: Sun, 5 Nov 2000 10:02:45 -0800
From: Alexandre Petit-Bianco <apbianco@xxxxxxxxxx>
To: java-announce@xxxxxxxxxxxxxxxxxx, gcc-announce@xxxxxxxxxxx
Subject: [ANNOUNCE] Libgcj relocation announce.

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	optionally 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.

==================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers)
Otpiswaneto RABOTI !!! : Majordomo@xxxxxxxxxxxxxxxxxx UNSUBSCRIBE LUG-BG
http://www.linux-bulgaria.org/ Hosted by Internet Group Ltd. - Stara Zagora