Patch: update documentation for gcj-eclipse merge

Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

This patch updates the documentation to reflect how things will work
after the gcj-eclipse merge is checked in.  I'd like this to be
approved so that I can commit it after I commit the merge.

With this merge, you need an 'ecj1' executable to get a fully
functioning gcj.  We provide a jar download and some configury to make
this simple to use; this patch adds a contrib/download_ecj script to
help with this.

This patch also documents the various prerequisites, new configure
flags, etc.

Ok?

Tom

gcc/doc
2007-01-05  Tom Tromey  <tromey@redhat.com>

	* doc/sourcebuild.texi (libgcj Tests): Don't mention jacks.
	* doc/install.texi (Testing): Don't mention jacks.
	(Configuration): Document --enable-java-maintainer-mode.  Move
	--with-java-home to libgcj-specific section.  Document
	--with-ecj-jar.
	(Prerequisites): Mention --enable-java-maintainer-mode, ecj1.

contrib
2007-01-05  Tom Tromey  <tromey@redhat.com>

	* download_ecj: New file.



Index: sourcebuild.texi
===================================================================
--- sourcebuild.texi	(.../trunk/gcc/doc)	(revision 118943)
+++ sourcebuild.texi	(.../branches/gcj/gcj-eclipse-merge-branch/gcc/doc)	(revision 120511)
@@ -1,4 +1,4 @@
-@c Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+@c Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -1299,14 +1299,8 @@
 Update this file when adding new failing tests to Mauve, or when fixing
 bugs in libgcj that had caused Mauve test failures.
 
-The @uref{http://sources.redhat.com/mauve/jacks.html,,
-Jacks} project provides a testsuite for Java compilers that can be used
-to test changes that affect the GCJ front end.  This testsuite is run as
-part of Java testing by placing the Jacks tree within the libjava
-testsuite sources at @file{libjava/testsuite/libjava.jacks/jacks}.
+We encourage developers to contribute test cases to Mauve.
 
-We encourage developers to contribute test cases to Mauve and Jacks.
-
 @node gcov Testing
 @subsection Support for testing @command{gcov}
 
Index: install.texi
===================================================================
--- install.texi	(.../trunk/gcc/doc)	(revision 118943)
+++ install.texi	(.../branches/gcj/gcj-eclipse-merge-branch/gcc/doc)	(revision 120511)
@@ -43,7 +43,7 @@
 @end ifset
 
 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
 @c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
 
 @c IMPORTANT: whenever you modify this file, run `install.texi2html' to
@@ -431,6 +431,17 @@
 Necessary when applying patches, created with @command{diff}, to one's
 own sources.
 
+@item ecj1
+@itemx gjavah
+
+If you wish to modify @file{.java} files in libjava, you will need to
+configure with @code{--enable-java-maintainer-mode}, and you will need
+to have executables named @code{ecj1} and @code{gjavah} on your path.
+The @code{ecj1} executable should run the Eclipse Java compiler via
+the GCC-specific entry point.  You can download a suitable jar from
+@uref{ftp://sources.redhat.com/pub/java/}, or by running the script
+@file{contrib/download_ecj}.
+
 @end table
 
 @html
@@ -1101,14 +1112,6 @@
 parallel.  This is currently supported by @samp{libgfortran},
 @samp{libjava}, @samp{libmudflap}, @samp{libstdc++}, and @samp{libobjc}.
 
-@item --with-java-home=@var{dirname}
-This @samp{libjava} option overrides the default value of the
-@samp{java.home} system property.  It is also used to set
-@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
-default @samp{java.home} is set to @file{@var{prefix}} and
-@samp{sun.boot.class.path} to
-@file{@var{datadir}/java/libgcj-@var{version}.jar}.
-
 @item --enable-languages=@var{lang1},@var{lang2},@dots{}
 Specify that only a particular subset of compilers and
 their runtime libraries should be built.  For a list of valid values for
@@ -1419,6 +1422,40 @@
 @subsubheading General Options
 
 @table @code
+@item --enable-java-maintainer-mode
+By default the @samp{libjava} build will not attempt to compile the
+@file{.java} source files to @file{.class}.  Instead, it will use the
+@file{.class} files from the source tree.  If you use this option you
+must have executables named @samp{ecj1} and @samp{gjavah} in your path
+for use by the build.  You must use this option if you intend to
+modify any @file{.java} files in @samp{libjava}.
+
+@item --with-java-home=@var{dirname}
+This @samp{libjava} option overrides the default value of the
+@samp{java.home} system property.  It is also used to set
+@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
+default @samp{java.home} is set to @file{@var{prefix}} and
+@samp{sun.boot.class.path} to
+@file{@var{datadir}/java/libgcj-@var{version}.jar}.
+
+@item --with-ecj-jar=@var{filename}
+This option can be used to specify the location of an external ``ecj''
+jar; that is, the jar file containing the Eclipse Java compiler.  A
+specially modified version of this compiler is used by @samp{gcj} to
+parse @file{.java} source files.  If this option is given, the
+@samp{libjava} build will create and install an @file{ecj1} executable
+which uses this jar file at runtime.
+
+If this option is not given, but an @file{ecj.jar} file is found in
+the topmost source tree at configure time, then the @samp{libgcj}
+build will create and install @file{ecj1}, and will also install the
+discovered @file{ecj.jar} into a suitable place in the install tree.
+
+If @file{ecj1} is not installed, then the user will have to supply one
+on his path in order for @samp{gcj} to properly parse @file{.java}
+source files.  A suitable jar is available from
+@uref{ftp://sources.redhat.com/pub/java}.
+
 @item --disable-getenv-properties
 Don't set system properties from @env{GCJ_PROPERTIES}.
 
@@ -1983,11 +2020,6 @@
 specifying the location of that tree when invoking @samp{make}, as in
 @samp{make MAUVEDIR=~/mauve check}.
 
-@uref{http://sources.redhat.com/mauve/jacks.html,,Jacks}
-is a free testsuite that tests Java compiler front ends.  This suite
-can be run as part of libgcj testing by placing the Jacks tree within
-the libjava testsuite at @file{libjava/testsuite/libjava.jacks/jacks}.
-
 @section How to interpret test results
 
 The result of running the testsuite are various @file{*.sum} and @file{*.log}

Index: download_ecj
===================================================================
--- download_ecj	(.../trunk/contrib)	(revision 0)
+++ download_ecj	(.../branches/gcj/gcj-eclipse-merge-branch/contrib)	(revision 120512)
@@ -0,0 +1,25 @@
+#! /bin/sh
+
+#
+# Download the ecj jar file needed by gcj.
+# Run this from the top level of the gcc source tree and the libjava
+# build will do the right thing.
+#
+# (C) 2006 Free Software Foundation
+#
+# This script is Free Software, and it can be copied, distributed and
+# modified as defined in the GNU General Public License.  A copy of
+# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
+#
+
+ftp -n sources.redhat.com << EOF
+verbose
+hash
+user ftp ''
+cd /pub/java
+binary
+get ecj-latest.jar
+EOF
+
+mv ecj-latest.jar ecj.jar
+

Re: Patch: update documentation for gcj-eclipse merge

[Gerald Pfeifer]

On Fri, 5 Jan 2007, Tom Tromey wrote:
> This patch also documents the various prerequisites, new configure
> flags, etc.

Some quick comments: Why do you remove all references to jacks?

I believe sourceware.org should be used as the canonical name of the 
machine in the new script.

> +If you wish to modify @file{.java} files in libjava, you will need to
> +configure with @code{--enable-java-maintainer-mode}, and you will 
need
                  ^^^^^
@option

> +to have executables named @code{ecj1} and @code{gjavah} on your path.

@command instead of @code (also later in this paragraph)

> +The @code{ecj1} executable should run the Eclipse Java compiler via
> +the GCC-specific entry point.  You can download a suitable jar from
> +@uref{ftp://sources.redhat.com/pub/java/}, or by running the script

Canonical hostname sourcware.org?

> +@file{contrib/download_ecj}.

@command, I believe.

> +@item --enable-java-maintainer-mode
> +By default the @samp{libjava} build will not attempt to compile the
> +@file{.java} source files to @file{.class}.  Instead, it will use the
> +@file{.class} files from the source tree.  If you use this option you
> +must have executables named @samp{ecj1} and @samp{gjavah} in your path

@command{ecj1}, @command{gjavah}

> +modify any @file{.java} files in @samp{libjava}.

I blieve we should use @file{libjava}, unless this is the name of the
library, in which case I'm not sure what would be best, probably 
@code{libjava} from what I have seen elsewhere.  (This also applies
to other parts of the patch.)

> +This option can be used to specify the location of an external ``ecj''
> +jar; that is, the jar file containing the Eclipse Java compiler.

How about "...location of an external jar file containing..."?

> +specially modified version of this compiler is used by @samp{gcj} to

@command

> +If @file{ecj1} is not installed, then the user will have to supply one
> +on his path in order for @samp{gcj} to properly parse @file{.java}

@command

> +source files.  A suitable jar is available from
> +@uref{ftp://sources.redhat.com/pub/java}.

I recommend adding a trailing slash to the URL, in addition to use 
sourceware.org.

The doc portions of this patch are fine modulo the comments above, as
far as I can tell.

Thanks,
Gerald

Re: Patch: update documentation for gcj-eclipse merge

[Richard Guenther]

On 05 Jan 2007 15:20:19 -0700, Tom Tromey <tromey@redhat.com> wrote:
> This patch updates the documentation to reflect how things will work
> after the gcj-eclipse merge is checked in.  I'd like this to be
> approved so that I can commit it after I commit the merge.
>
> With this merge, you need an 'ecj1' executable to get a fully
> functioning gcj.  We provide a jar download and some configury to make
> this simple to use; this patch adds a contrib/download_ecj script to
> help with this.
>
> This patch also documents the various prerequisites, new configure
> flags, etc.

I have a couple of questions here.  I presume ecj1 is needed for source to
bytecode translation and ecj1 is not necessary for bytecode to native
translation?  If you distribute ecj1 from sourceware.org you also need to
distribute source?  (This is a question also for distributors of binaries
for gcc - if they include java support and ecj1, do they need to distribute
the source to ecj1?)  Do you expect possible problems if we don't use
the 'latest' ecj1 with trunk but an earlier version?  What about the other
way around?  [I'm basically thinking on how to do a sensible setup
for packaging gcc in the future]

Thanks,
Richard.

Re: Patch: update documentation for gcj-eclipse merge

[Andrew Haley]

Richard Guenther writes:
 > On 05 Jan 2007 15:20:19 -0700, Tom Tromey <tromey@redhat.com> wrote:
 > > This patch updates the documentation to reflect how things will work
 > > after the gcj-eclipse merge is checked in.  I'd like this to be
 > > approved so that I can commit it after I commit the merge.
 > >
 > > With this merge, you need an 'ecj1' executable to get a fully
 > > functioning gcj.  We provide a jar download and some configury to make
 > > this simple to use; this patch adds a contrib/download_ecj script to
 > > help with this.
 > >
 > > This patch also documents the various prerequisites, new configure
 > > flags, etc.
 > 
 > I have a couple of questions here.  I presume ecj1 is needed for source to
 > bytecode translation and ecj1 is not necessary for bytecode to native
 > translation?

Correct.  At leat, I'm pretty certain that the EPL requires that, but
even if it didn't it would be irresponsible to make the sources
available, so it's safe to assume so.  Here's the wordage:

--------------------------------------------------------------------------
3. REQUIREMENTS

A Contributor may choose to distribute the Program in object code form
under its own license agreement, provided that:

a) it complies with the terms and conditions of this Agreement; and

b) its license agreement:

i) effectively disclaims on behalf of all Contributors all warranties
and conditions, express and implied, including warranties or
conditions of title and non-infringement, and implied warranties or
conditions of merchantability and fitness for a particular purpose;

ii) effectively excludes on behalf of all Contributors all liability
for damages, including direct, indirect, special, incidental and
consequential damages, such as lost profits;

iii) states that any provisions which differ from this Agreement are
offered by that Contributor alone and not by any other party; and

iv) states that source code for the Program is available from such
Contributor, and informs licensees how to obtain it in a reasonable
manner on or through a medium customarily used for software exchange.


... more elided
--------------------------------------------------------------------------

 > If you distribute ecj

 > If you distribute ecj1 from sourceware.org you also need to
 > distribute source?

Also correct.

 > (This is a question also for distributors of binaries for gcc - if
 > they include java support and ecj1, do they need to distribute the
 > source to ecj1?) 

Yes.

 > Do you expect possible problems if we don't use the 'latest' ecj1
 > with trunk but an earlier version?  What about the other way
 > around?  [I'm basically thinking on how to do a sensible setup for
 > packaging gcc in the future]

There aren't any really bad problems AFAIAA, but binaries may be
slightly different.  You'd have to be careful when committing .class
files back to the libgcj tree that you didn't commit a ton of
unnecessary changes, but anyone with write privileges is supposed to
*look* at the files they're committing!

The script contrib/download_ecj downloads a common version of ecj, and
we'd hope that gcj maintainers would use that one; this will surely
reduce the potential screwups.

Andrew.

Re: Patch: update documentation for gcj-eclipse merge

[Andrew Haley]

Andrew Haley writes:
 > 
 > Correct.  At leat, I'm pretty certain that the EPL requires that, but
 > even if it didn't it would be irresponsible to make the sources
 > available,

Ooooh.  _NOT_ to make the sources available.

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> Correct.  At leat, I'm pretty certain that the EPL requires that, but
Andrew> even if it didn't it would be irresponsible to make the sources
Andrew> available, so it's safe to assume so.

Yeah... this is on my to-do list, along with a half dozen other
finalizing things.  I'm sorry I put it off so long.

>> Do you expect possible problems if we don't use the 'latest' ecj1
>> with trunk but an earlier version?  What about the other way
>> around?  [I'm basically thinking on how to do a sensible setup for
>> packaging gcc in the future]

Andrew> There aren't any really bad problems AFAIAA, but binaries may be
Andrew> slightly different.  You'd have to be careful when committing .class
Andrew> files back to the libgcj tree that you didn't commit a ton of
Andrew> unnecessary changes, but anyone with write privileges is supposed to
Andrew> *look* at the files they're committing!

Andrew> The script contrib/download_ecj downloads a common version of ecj, and
Andrew> we'd hope that gcj maintainers would use that one; this will surely
Andrew> reduce the potential screwups.

I forgot to mention maintenance of ecj1 in my posts on this topic.

Since ecj will change over time, and since all these generated files
are checked in, we will have to handle ecj1 much the same way that we
handle the auto tools.  That is, all developers will have to use the
same version.  Anything else will lead to chaos.

I think the simplest thing is to have a blessed version of ecj for
each release branch.  We can modify download_ecj on such a branch to
download a separate file.

When we want to update ecj1 for the trunk, we can make a new
'ecj-latest.jar', upload it, and then regenerate all the class files
on the trunk, check them in, and send out email telling all gcj
developers that they must download a new version.

Any comments on this?  I made a note to document the ecj1 maintenance
process; I'll have to look up where this would go.

What distros do is of course up to them.  For Fedora I believe our
current plan is to make a special "ecj only" RPM based on the eclipse
compiler sources plus GCCMain.java (the ecj1 driver code).  GCCMain is
available from sourceware.org:/cvs/rhug, module 'eclipse-gcj'.  It
drops into the eclipse compiler source tree.

Tom

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

>> This patch also documents the various prerequisites, new configure
>> flags, etc.

Gerald> Some quick comments: Why do you remove all references to jacks?

My original note mentioned this but I edited it out :)

Jacks is a test suite for Java language compliance.  Since we've
outsourcing Java parsing and semantic analysis, there's no point in us
running Jacks.  I've removed this code from the libjava test suite.

Gerald> The doc portions of this patch are fine modulo the comments
Gerald> above, as far as I can tell.

I'll fix all these things soon.

Tom

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> I believe sourceware.org should be used as the canonical name of the 
Gerald> machine in the new script.

BTW while looking at this I found that the docs on svn trunk mostly
refer to sources.redhat.com.  In my tree there's only one reference to
sourceware.org.  So I suppose this is a good topic for a cleanup patch...

Tom

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

Andrew> Correct.  At leat, I'm pretty certain that the EPL requires that, but
Andrew> even if it didn't it would be irresponsible to make the sources
Andrew> available, so it's safe to assume so.

Tom> Yeah... this is on my to-do list, along with a half dozen other
Tom> finalizing things.  I'm sorry I put it off so long.

I've uploaded the sources to sourceware.org.
These are the sources I used to make ecj-latest.jar.

Tom

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> The doc portions of this patch are fine modulo the comments above, as
Gerald> far as I can tell.

Here's an updated version of the patch.

Tom

Index: gcc/ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* doc/sourcebuild.texi (libgcj Tests): Don't mention jacks.
	* doc/install.texi (Testing): Don't mention jacks.
	(Configuration): Document --enable-java-maintainer-mode.  Move
	--with-java-home to libgcj-specific section.  Document
	--with-ecj-jar.
	(Prerequisites): Mention --enable-java-maintainer-mode, ecj1.

Index: contrib/ChangeLog
from  Tom Tromey  <tromey@redhat.com>

	* download_ecj: New file.

Index: gcc/doc/sourcebuild.texi
===================================================================
--- gcc/doc/sourcebuild.texi	(revision 120448)
+++ gcc/doc/sourcebuild.texi	(working copy)
@@ -1,4 +1,4 @@
-@c Copyright (C) 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
+@c Copyright (C) 2002, 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -1299,14 +1299,8 @@
 Update this file when adding new failing tests to Mauve, or when fixing
 bugs in libgcj that had caused Mauve test failures.
 
-The @uref{http://sources.redhat.com/mauve/jacks.html,,
-Jacks} project provides a testsuite for Java compilers that can be used
-to test changes that affect the GCJ front end.  This testsuite is run as
-part of Java testing by placing the Jacks tree within the libjava
-testsuite sources at @file{libjava/testsuite/libjava.jacks/jacks}.
+We encourage developers to contribute test cases to Mauve.
 
-We encourage developers to contribute test cases to Mauve and Jacks.
-
 @node gcov Testing
 @subsection Support for testing @command{gcov}
 
Index: gcc/doc/install.texi
===================================================================
--- gcc/doc/install.texi	(revision 120448)
+++ gcc/doc/install.texi	(working copy)
@@ -43,7 +43,7 @@
 @end ifset
 
 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
+@c 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
 @c *** Converted to texinfo by Dean Wakerley, dean@wakerley.com
 
 @c IMPORTANT: whenever you modify this file, run `install.texi2html' to
@@ -431,6 +431,17 @@
 Necessary when applying patches, created with @command{diff}, to one's
 own sources.
 
+@item ecj1
+@itemx gjavah
+
+If you wish to modify @file{.java} files in libjava, you will need to
+configure with @option{--enable-java-maintainer-mode}, and you will need
+to have executables named @command{ecj1} and @command{gjavah} on your path.
+The @command{ecj1} executable should run the Eclipse Java compiler via
+the GCC-specific entry point.  You can download a suitable jar from
+@uref{ftp://sourceware.org/pub/java/}, or by running the script
+@command{contrib/download_ecj}.
+
 @end table
 
 @html
@@ -1101,14 +1112,6 @@
 parallel.  This is currently supported by @samp{libgfortran},
 @samp{libjava}, @samp{libmudflap}, @samp{libstdc++}, and @samp{libobjc}.
 
-@item --with-java-home=@var{dirname}
-This @samp{libjava} option overrides the default value of the
-@samp{java.home} system property.  It is also used to set
-@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
-default @samp{java.home} is set to @file{@var{prefix}} and
-@samp{sun.boot.class.path} to
-@file{@var{datadir}/java/libgcj-@var{version}.jar}.
-
 @item --enable-languages=@var{lang1},@var{lang2},@dots{}
 Specify that only a particular subset of compilers and
 their runtime libraries should be built.  For a list of valid values for
@@ -1420,6 +1423,40 @@
 @subsubheading General Options
 
 @table @code
+@item --enable-java-maintainer-mode
+By default the @samp{libjava} build will not attempt to compile the
+@file{.java} source files to @file{.class}.  Instead, it will use the
+@file{.class} files from the source tree.  If you use this option you
+must have executables named @command{ecj1} and @command{gjavah} in your path
+for use by the build.  You must use this option if you intend to
+modify any @file{.java} files in @file{libjava}.
+
+@item --with-java-home=@var{dirname}
+This @samp{libjava} option overrides the default value of the
+@samp{java.home} system property.  It is also used to set
+@samp{sun.boot.class.path} to @file{@var{dirname}/lib/rt.jar}.  By
+default @samp{java.home} is set to @file{@var{prefix}} and
+@samp{sun.boot.class.path} to
+@file{@var{datadir}/java/libgcj-@var{version}.jar}.
+
+@item --with-ecj-jar=@var{filename}
+This option can be used to specify the location of an external jar
+file containing the Eclipse Java compiler.  A specially modified
+version of this compiler is used by @command{gcj} to parse
+@file{.java} source files.  If this option is given, the
+@samp{libjava} build will create and install an @file{ecj1} executable
+which uses this jar file at runtime.
+
+If this option is not given, but an @file{ecj.jar} file is found in
+the topmost source tree at configure time, then the @samp{libgcj}
+build will create and install @file{ecj1}, and will also install the
+discovered @file{ecj.jar} into a suitable place in the install tree.
+
+If @file{ecj1} is not installed, then the user will have to supply one
+on his path in order for command{gcj} to properly parse @file{.java}
+source files.  A suitable jar is available from
+@uref{ftp://sourceware.org/pub/java/}.
+
 @item --disable-getenv-properties
 Don't set system properties from @env{GCJ_PROPERTIES}.
 
@@ -1984,11 +2021,6 @@
 specifying the location of that tree when invoking @samp{make}, as in
 @samp{make MAUVEDIR=~/mauve check}.
 
-@uref{http://sources.redhat.com/mauve/jacks.html,,Jacks}
-is a free testsuite that tests Java compiler front ends.  This suite
-can be run as part of libgcj testing by placing the Jacks tree within
-the libjava testsuite at @file{libjava/testsuite/libjava.jacks/jacks}.
-
 @section How to interpret test results
 
 The result of running the testsuite are various @file{*.sum} and @file{*.log}
Index: contrib/download_ecj
===================================================================
--- contrib/download_ecj	(revision 0)
+++ contrib/download_ecj	(revision 0)
@@ -0,0 +1,25 @@
+#! /bin/sh
+
+#
+# Download the ecj jar file needed by gcj.
+# Run this from the top level of the gcc source tree and the libjava
+# build will do the right thing.
+#
+# (C) 2006 Free Software Foundation
+#
+# This script is Free Software, and it can be copied, distributed and
+# modified as defined in the GNU General Public License.  A copy of
+# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
+#
+
+ftp -n sourceware.org << EOF
+verbose
+hash
+user ftp ''
+cd /pub/java
+binary
+get ecj-latest.jar
+EOF
+
+mv ecj-latest.jar ecj.jar
+

Property changes on: contrib/download_ecj
___________________________________________________________________
Name: svn:executable
   + *

Re: Patch: update documentation for gcj-eclipse merge

[Gerald Pfeifer]

On Mon, 8 Jan 2007, Tom Tromey wrote:
>> The doc portions of this patch are fine modulo the comments above, as
>> far as I can tell.
> Here's an updated version of the patch.

Duh, I thought you'd go ahead and commit the patch with some changes,
at least that's what I had ment to imply. =:-)  Sorry for the delay.

> from  Tom Tromey  <tromey@redhat.com>
> 
> 	* doc/sourcebuild.texi (libgcj Tests): Don't mention jacks.
> 	* doc/install.texi (Testing): Don't mention jacks.
> 	(Configuration): Document --enable-java-maintainer-mode.  Move
> 	--with-java-home to libgcj-specific section.  Document
> 	--with-ecj-jar.
> 	(Prerequisites): Mention --enable-java-maintainer-mode, ecj1.

The doc changes are fine.  (Did you intentionally sort the ChangeLog
entries in reverse order?)

I cannot approve contrib/download_ecj, but let's just go for it, I'd
say.  No need to get overly anal here.

> +If you wish to modify @file{.java} files in libjava, you will need to
> +configure with @option{--enable-java-maintainer-mode}, and you will need
> +to have executables named @command{ecj1} and @command{gjavah} on your path.

"in your path"?  Not sure about this one.

Gerald

Re: Patch: update documentation for gcj-eclipse merge

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> Duh, I thought you'd go ahead and commit the patch with some changes,
Gerald> at least that's what I had ment to imply. =:-)  Sorry for the delay.

:)  No problem.

Gerald> The doc changes are fine.  (Did you intentionally sort the ChangeLog
Gerald> entries in reverse order?)

Nope.  I'm afraid I usually don't pay too much attention to the order
in which I put the entries.

Gerald> I cannot approve contrib/download_ecj, but let's just go for it, I'd
Gerald> say.  No need to get overly anal here.

Ok, thanks.

>> +If you wish to modify @file{.java} files in libjava, you will need to
>> +configure with @option{--enable-java-maintainer-mode}, and you will need
>> +to have executables named @command{ecj1} and @command{gjavah} on your path.

Gerald> "in your path"?  Not sure about this one.

I grepped and the existing docs seem to use "in" rather than "on".
So, I will make this change and check it all in.  Thanks for your review.

Tom