This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: update documentation for gcj-eclipse merge


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]