>>>>> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
