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 having
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
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 decided to
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 either.
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 all of
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 tarball
6 matches
Mail list logo
