Re: Hacking Classpath in Eclipse
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> My current fake jdk here just makes a bunch of symlinks and then Tom> builds a .jar. But I'm considering moving the jar-making step into Tom> Classpath and having it run in the background... I'll try to play with Tom> this soon. I tried this out and it seems to work great. The key is to make the jar builder run in the background. At least, with my basic testing, this doesn't result in a noticeable build performance drop. I'll check in my fake jdk project to the rhug cvs soon. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On Thu, 2005-12-22 at 09:05 -0700, Tom Tromey wrote: > Tom> This is an example of why it would be very useful to make Classpath > Tom> fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into > Tom> the Classpath repository/build system. Long term I guess this is where > Tom> we're headed but this is just another data point that we're going in the > Tom> right direction. > > For Eclipse-based builds we really don't want all of this; in > particular we don't want or need a compiler here. Using the built-in > Eclipse compiler is superior. > > >> Ideally Eclipse would offer the possibility of auto-exporting the > >> build results as a .jar. That would solve this entirely. > > Tom> Yes, I've wanted that in several other situations. Let's file an > Tom> enhancement bug with Eclipse. > > Are you filing it? If so tell me the PR and I will add myself. https://bugs.eclipse.org/bugs/show_bug.cgi?id=121901 Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
Tom> This is an example of why it would be very useful to make Classpath Tom> fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into Tom> the Classpath repository/build system. Long term I guess this is where Tom> we're headed but this is just another data point that we're going in the Tom> right direction. For Eclipse-based builds we really don't want all of this; in particular we don't want or need a compiler here. Using the built-in Eclipse compiler is superior. >> Ideally Eclipse would offer the possibility of auto-exporting the >> build results as a .jar. That would solve this entirely. Tom> Yes, I've wanted that in several other situations. Let's file an Tom> enhancement bug with Eclipse. Are you filing it? If so tell me the PR and I will add myself. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
> "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 Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote: > > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: > > Mark> I found a cute hack to actually run a single mauve Testlet from within > Mark> eclipse using the just compiled classpath: > > Mark> $ mkdir -p ~/workspace/classpath/install/jre/lib > Mark> $ touch ~/workspace/classpath/install/jre/lib/rt.jar > > Mark> Now as by magic you can add ~/workspace/classpath/install as JRE to > Mark> eclipse (under Preferences -> Java -> JREs) and then configure Runners > Mark> to use that alternative jre. > > 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. This is an example of why it would be very useful to make Classpath fully bootstrappable by merging e.g. cp-tools, gjdoc, gij and gcjx into the Classpath repository/build system. Long term I guess this is where we're headed but this is just another data point that we're going in the right direction. > > Ideally Eclipse would offer the possibility of auto-exporting the > build results as a .jar. That would solve this entirely. Yes, I've wanted that in several other situations. Let's file an enhancement bug with Eclipse. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
On 12/22/05, Mark Wielaard <[EMAIL PROTECTED]> wrote: > 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.) Yeah, I had the same thought, but not time yet to investigate a way to patch Eclipse, so that you can specify more details. It's definitely on my TODO list. Stephan Michels. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
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
Re: Hacking Classpath in Eclipse
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> I found a cute hack to actually run a single mauve Testlet from within Mark> eclipse using the just compiled classpath: Mark> $ mkdir -p ~/workspace/classpath/install/jre/lib Mark> $ touch ~/workspace/classpath/install/jre/lib/rt.jar Mark> Now as by magic you can add ~/workspace/classpath/install as JRE to Mark> eclipse (under Preferences -> Java -> JREs) and then configure Runners Mark> to use that alternative jre. 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. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
Hi, On Tue, 2005-12-20 at 17:53 -0700, Tom Tromey wrote: > We think it is now ready for a wider audience. You can read it here: > > http://developer.classpath.org/mediation/ClasspathHackingWithEclipse > > This document will walk you through setting up Eclipse, checking out > Classpath, Cacao, and Mauve, and then trying them out. This is still > a work in progress, but we think the instructions here should > generally work ok. I played a bit more with it and it certainly has potential. The most impressive thing is how well native Eclipse actually works! In the past eclipse didn't really feel that stable, but the versions that come with Fedora and Debian seem pretty solid out of the box. It is clear we did a lot of stabilizing in the last couple of months. The single Mauve testlet example is pretty nice. Since if everything is setup a simple edit and save of a core library file is enough to retest the Testlet and immediately see PASS/FAIL results. I found a cute hack to actually run a single mauve Testlet from within eclipse using the just compiled classpath: $ mkdir -p ~/workspace/classpath/install/jre/lib $ touch ~/workspace/classpath/install/jre/lib/rt.jar Now as by magic you can add ~/workspace/classpath/install as JRE to eclipse (under Preferences -> Java -> JREs) and then configure Runners to use that alternative jre. I added a quick SingleTestHarness and MauveRun Runner to mauve as an example. With it you can immediately run a mauve Testlet that you are working on against the classpath code you are hacking inside eclipse. I have to get me some sleep now, but I will add it to the wiki tomorrow if nobody beats me to it. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Hacking Classpath in Eclipse
Recently Raif wrote a nice white paper on how to hack on Classpath using Eclipse. Mark turned this into a wiki page, and then the three of us spent some time editing it. We think it is now ready for a wider audience. You can read it here: http://developer.classpath.org/mediation/ClasspathHackingWithEclipse This document will walk you through setting up Eclipse, checking out Classpath, Cacao, and Mauve, and then trying them out. This is still a work in progress, but we think the instructions here should generally work ok. Tom ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
