Re: Hacking Classpath in Eclipse

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <address@hidden> writes:

>> Ideally Eclipse would offer the possibility of auto-exporting the
>> build results as a .jar.  That would solve this entirely.

Mark> Wouldn't it be enough if we could convince eclipse to accept a
Mark> "hand-made jre"? I mean one where you can you explicitly set the
Mark> individual binaries that make up the tools that eclipse expects? Plus
Mark> convincing the built-in eclipse compiler to use a flat (non-jar/zip)
Mark> bootclasspath?

Yeah, this approach would work as well.
I've been mostly looking for a quick hack, since I don't want to
spend a lot of time on this.  Eclipse won't let you set up a standard
vm whose boot class path is a directory, I tried that.  I wonder if a
'glibj.jar -> .' symlink would work :-).  (Doubtful)

My current fake jdk here just makes a bunch of symlinks and then
builds a .jar.  But I'm considering moving the jar-making step into
Classpath and having it run in the background... I'll try to play with
this soon.  I can send the symlink script if you want it, it is
just the dumb/obvious thing.

Mark> If you take a quick look at
Mark> org/eclipse/jdt/internal/launching/StandardVMType.java it looks like
Mark> this class just needs a set of setters and a way to override that auto
Mark> detection. Or maybe we need a new subclass of AbstractVMType that
Mark> creates an IVMInstall just based on user defined locations that can be
Mark> plugged into the standard JRE preferences dialog as override to the
Mark> autodetecting StandardVMType?

Yeah, I looked at this a little.  There is an extension point for this
(org.eclipse.jdt.launching.vmInstallTypes) so you can make your own
plugin that provides a new type of VM.  It is unclear whether this can
use a flat install (but maybe the problem is the documentation and not
the code -- I didn't try).

Tom