Hi, On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote: > Note that this will work for running something, but not if you want > to compile against that JRE. > > For the latter I think we need to come up with some kind of "fake jdk" > project. I actually have the start of one here, but I haven't > finished polishing it yet. > > Ideally Eclipse would offer the possibility of auto-exporting the > build results as a .jar. That would solve this entirely.
Wouldn't it be enough if we could convince eclipse to accept a "hand-made jre"? I mean one where you can you explicitly set the individual binaries that make up the tools that eclipse expects? Plus convincing the built-in eclipse compiler to use a flat (non-jar/zip) bootclasspath? (I believe ecj can use dirs already, but haven't checked.) It feels like eclipse is just trying to be too clever in its "jre detection". Maybe if the "JRE definitions" preference box had an "override - I know what I am doing" box, so you could fill in the individual parts that make up the "StandardVMType" thing. If you take a quick look at org/eclipse/jdt/internal/launching/StandardVMType.java it looks like this class just needs a set of setters and a way to override that auto detection. Or maybe we need a new subclass of AbstractVMType that creates an IVMInstall just based on user defined locations that can be plugged into the standard JRE preferences dialog as override to the autodetecting StandardVMType? Cheers, Mark
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath