Bug 28938 - [ecj] update build instructions to account for changes
Summary: [ecj] update build instructions to account for changes
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: 4.3.0
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks: 28067
  Show dependency treegraph
 
Reported: 2006-09-02 17:48 UTC by Tom Tromey
Modified: 2007-01-26 00:01 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-01-09 20:50:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2006-09-02 17:48:44 UTC
The gcc build instructions must be updated for gcj-eclipse changes
before we can merge the branch.
Comment 1 Paolo Bonzini 2006-09-13 10:43:05 UTC
A somewhat disconnected comment on the ecj-branch build process...

Are you planning to distribute ecj as a JAR file too?  If so, there should be no changes to the documentation for building out of tarballs.

If you don't want to put the JAR in svn, To build from svn, a pre-existing GCJ would be necessary that can build ecj.

The build process should go like this:

- the gcc directory builds the bytecode->native compiler
- if there is a JAR, the ecj directory looks for ../gcc/gcj and uses that one to build the native compiler
- if not, the toplevel configury should pass the path to a GCJ somewhere and the ecj directory will use it to build the JAR.  I think the JAR should be built in the build directory, unless --enable-generated-files-in-srcdir.

more on the third bullet: find the GCJ in the toplevel, as we do for C++ (grep for CXX= in the toplevel configure -- there is room for improvement but I don't think it's important).  In the Makefile.tpl, add somewhere

  GCJ=@GCJ@

and pass it down to ecj via HOST_FLAGS_TO_PASS.

Later on, ecj could even be bootstrapped using POSTSTAGE1_FLAGS_TO_PASS to point to the just build gcj and ecj.  (How does gcj find the ecj to use?  Might this require spec hacking?)
Comment 2 Tom Tromey 2006-09-20 17:04:09 UTC
Yes, I plan on making an ecj jar download available.
In the near term I will put one on gcc.gnu.org (or elsewhere).
In the longer term I plan to get my ecj changes upstream, and then
we will be able to point people at the official eclipse.org download
(eclipse.org started releasing separate ecj jars recently).

Our particular ecj has a new driver which is tailored for gcc's use.
gcj on the branch looks for a program called "ecj1".
I just have this as a simple shell script, but there are any number of
ways to do this... eg you could compile ecj.jar to an executable using
gcj.

This is found using the normal gcc specs approach.  In a distribution
I'd expect ecj1 to end up in the gcc-lib dir.  In my case I just have
it on my PATH.

We won't be including the ecj sources in the gcc tree.  As I recall that
was rejected by the SC.  So it will always be a separate download.

We also require a new version of gcjh.  This is also written in java.
The code is part of GNU Classpath, but instead of struggling with the
bootstrap issues there, I'll again just make a downloadable jar.

Both ecj and the new gcjh can be run on any vm, including all the free
ones.  I've built libgcj many times running these purely interpreted
and it is not painfully slow.
Comment 3 paolo.bonzini@lu.unisi.ch 2006-09-21 08:21:08 UTC
Subject: Re:  [ecj] update build instructions to account for
 changes


> This is found using the normal gcc specs approach.  In a distribution
> I'd expect ecj1 to end up in the gcc-lib dir.  In my case I just have
> it on my PATH.
>
> We won't be including the ecj sources in the gcc tree.  As I recall that
> was rejected by the SC.  So it will always be a separate download.
>   
The best thing would be if I could just "sudo apt-get install ecj".  If 
there are any differences between ecj and ecj1, we should provide some 
kind of wrapper.  A nice possibility, would be to support dropping the 
downloaded JAR somewhere in the tree where it installs correctly and 
automagically.  This would not be against the SC decision.
> Both ecj and the new gcjh can be run on any vm, including all the free
> ones.  I've built libgcj many times running these purely interpreted
> and it is not painfully slow.
Cool, though not unexpected because the code generation of Java 
bytecodes is not that hard (apart from the unreachable and uninitialized 
code checking).

Paolo
Comment 4 Tom Tromey 2006-09-21 17:07:41 UTC
Maybe a --with-installed-ecj-jar=/path option would be good.
Then a distro like fedora could build gcj by pointing it at
an already-installed ecj; we could install a little sh script
in the right place that would run gij properly.

Comment 5 Tom Tromey 2006-10-18 23:36:41 UTC
Subject: Bug 28938

Author: tromey
Date: Wed Oct 18 23:36:32 2006
New Revision: 117868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117868
Log:
	PR java/28938:
	* doc/install.texi (Prerequisites): Mention ecj1.
	(Configuration): Move --with-java-home to libgcj-specific
	section.  Document --with-ecj-jar.

Modified:
    branches/gcj-eclipse/gcc/ChangeLog
    branches/gcj-eclipse/gcc/doc/install.texi

Comment 6 Tom Tromey 2006-10-18 23:37:27 UTC
Note that this isn't quite fixed yet, as we haven't documented
how to handle gcjh.
Comment 7 Tom Tromey 2007-01-26 00:01:04 UTC
I think this is fixed now.