public inbox for eclipse@sourceware.org
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Jan Schulz <jasc.usenet@gmx.de>
Cc: eclipse@sources.redhat.com
Subject: Re: Recognizing gcj as default StandardVM (JRE System Library)
Date: Sat, 02 Aug 2003 16:55:00 -0000	[thread overview]
Message-ID: <87k79wqa3s.fsf@fleche.redhat.com> (raw)
In-Reply-To: <20030802154316.GA4009@katzien.de>

>>>>> "Jan" == Jan Schulz <jasc.usenet@gmx.de> writes:

>> It took me some time to convince eclipse to recognize gcj/gij/libgcj as
>> standard vm.

Jan> Does this mean that eclipse will run with a (patched?) gcj as
Jan> '*/bin/java' (not native, but in the VM)?

What Mark is talking about is using the JDT with gcj.  Right now that
is not easy to set up.

Note that once you have it set up, it still isn't perfect.  There is
no way to debug this setup with the JDT debugger.  One idea to make a
gdb wrapper that can speak JDWP.  I'm not sure if we're going to do
this or not.

Jan> [running natively]
Jan> What will happen with all the plugins? Are they still recognised when
Jan> eclipse is started as native binary? Are they still runable? 

We compile all the plugins we can, but not all of them are compiled.
In some cases libgcj is missing a needed package.  (And in some of
these cases we could remove a class or two and make it work -- e.g.,
sharing with the precompiled ant and tomcat is on our to-do list...)

So, we can still interpret the plugins that are not compiled.

One thing we'd like to do is modify the PDE to teach it about gcj.
Then it would be really easy to compile your own plugins.  This would
probably speed up compilation as well, since right now we just stick
everything on the class path for each compilation -- ugly.

Tom

  reply	other threads:[~2003-08-02 16:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-02 13:55 Mark Wielaard
2003-08-02 15:44 ` Jan Schulz
2003-08-02 16:55   ` Tom Tromey [this message]
2003-08-02 21:54     ` Mark Wielaard
2003-08-02 21:45   ` Mark Wielaard
2003-08-02 16:07 ` Tom Tromey
2003-08-08 16:08 ` Andrew Haley
2003-08-14 17:38   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k79wqa3s.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=eclipse@sources.redhat.com \
    --cc=jasc.usenet@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).