Re: Eclipse and Classpath

[Mark Wielaard]

Hi,

On Fri, 2004-04-23 at 19:59, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <address@hidden> writes:
> 
> Mark> There are a couple of things that I am worried about:
> 
> Mark> - Having multiple build systems were we have enough maintenance
> Mark>   work with the current one.
> 
> Yeah, make no mistake, if we encourage people to use IDEs, it will
> eventually have some effect.  For instance, if we ever want to start
> doing preprocessing, we'll run into conflicts.  (Personally I don't
> see this as a big problem, since I'm not that keen on preprocessing,
> but I know there are differences here already.)

Just see the Configuration.java[.in] file for the smallest example.
(Even though most things in that file should probably be provided
through the Runtime/System properties). The only thing that is really
essential in that file is probably the VERSION and DEBUG flags. If that
is really it then we might consider just keeping them up to date by hand
(kind of like we currently do with the jni header files).

> On the other hand, some effects of IDEs are beneficial.  As we've
> already seen, Eclipse has a good compiler which has already found real
> Classpath bugs.

Yeah, but we can also get that with ecj (the gcj native compiled Eclipse
Compiler from RHUG http://sources.redhat.com/rhug/) which is simple to
integrate with the current build system.

> Mark> - Pretending we support Eclipse which is arguably non-free since people
> Mark>   are not testing, running and developing it with free runtimes.
> Mark>   (You claim adding this might make this happen sooner. I do hope so.)
> 
> I did all my work with Eclipse running on a free runtime.  And AFAIK
> Eclipse 2.x works out of the box with many runtimes, including gcc 3.4
> (just released).

OK I checked. Kaffe (1.1.4, debian pacakge) does run Eclipse 2.1.2, but
isn't stable enough for hacking on GNU Classpath. jamvm + 0.09-pre is
almost there it seems but doesn't startup completely (some strange crash
deep in GTK+ with 2.1.2, 3.0M8 just hangs half way during startup eating
up lots of CPU, dunno why). Jikes RVM prototype build bootstrapped from
kaffe seems to work, but does crash occasionally. The development build
crashes pretty quickly. Jeroen reports that IKVM.NET + Mono even runs
Eclipse 3.0M8 correctly, haven't tried that yet.

I reinstalled the native Eclipse from http://sources.redhat.com/eclipse/
and that does indeed work nicely with your project and classpath files.
gij 3.5 (CVS) does work, but needs some tweaking
(http://gcc.gnu.org/ml/java/2004-04/msg00246.html). gij 3.4 (from Debian
experimental) does indeed startup 2.1.2, but has troubles with the java
view (which is kind of essential if you want to use Eclipse for GNU
Classpath hacking):

!MESSAGE Problems occurred when invoking code from plug-in: 
"org.eclipse.ui.workbench".
!STACK 0
java.lang.VerifyError: verification failed at PC 22 in 
org.eclipse.jdt.ui.actions.FindReferencesAction:<init>((Lorg.eclipse.ui.IWorkbenchSite;)V):
 uninitialized object in local variable
   at _Jv_BytecodeVerifier.verify_fail(byte, int) (/usr/lib/libgcj.so.5.0.0)

I guess it would work when disabling the verifier, but I was to lazy
(and out of diskspace) to try to recompile libgcj from source.

> Mark> If you can show me some people that run Eclipse in a free environment
> Mark> that are actually happy with using your setup files than I am all for
> Mark> including them. But you must promise to maintain them. The only hard
> Mark> part seem to come up with the list of "classpaths" and the "exclusion
> Mark> list", which is done by hand in our normal build system also.
> 
> Yeah, I'll do this.  There really isn't much to maintain.  I think the
> worst case is if nobody uses these and they rot.  But if that happens,
> then we know people aren't using Eclipse to hack Classpath, and the
> solution is simple: cvs rm.

OK. Thanks.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part