On Wed, Sep 14, 2005 at 07:11:16PM -0500, Billy Biggs wrote:
> Shaun Jackman ([EMAIL PROTECTED]):
>
> > Keeping SWT and Eclipse in different source packages allows the two
> > packages to be maintained independently, which I think is a major
> > plus. For one, this allows SWT to be patched without
Shaun Jackman ([EMAIL PROTECTED]):
> Keeping SWT and Eclipse in different source packages allows the two
> packages to be maintained independently, which I think is a major
> plus. For one, this allows SWT to be patched without having to rebuild
> Eclipse and vice versa. An autoconf'ed SWT tarbal
> That may sound like a pretty bad answer though, and feels even worse
> now that I'm typing it. I've been thinking that the correct answer is
> to have SWT packages created from the full eclipse sources like
> Michael's packages do, and then ideally we'll do a proper autoconf
> framework for al
Shaun Jackman ([EMAIL PROTECTED]):
> I'm building the Debian package from the source distribution src.zip
> in swt-3.1-gtk-linux-x86.zip. This build.xml does not contain a
> replace.32.to.64 target, and neither does
> swt-3.1-gtk-linux-x86_64.zip. There is no org/eclipse/swt/tools
> directory eith
2005/9/14, Billy Biggs <[EMAIL PROTECTED]>:
> Hi, I just got pointed at this bug, I am a developer on the SWT
> project.
>
> The issue here is that in Java memory we need to store pointers to C
> objects. jint is 32 bits, jlong is 64 bits, by the Java spec. To keep
> memory use down, we deci
Hi, I just got pointed at this bug, I am a developer on the SWT
project.
The issue here is that in Java memory we need to store pointers to C
objects. jint is 32 bits, jlong is 64 bits, by the Java spec. To keep
memory use down, we decided to have the Java and C code for 64-bit GTK+
ports be
6 matches
Mail list logo
