Hi, On Fri, 2004-04-23 at 19:59, Tom Tromey wrote: > >>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> 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
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
