Trying to compile qtjava

[Thomas Zander]

Since a few weeks I have been blessed with a new laptop, which is fast
enough to try to get kdebindings (3.5 branch) to compile again. (I never
actually got it working at all).

After finding out that unsermake is unsupported I tried the old make stuff
in a src==builddir. I.e. no features.

I actually got some to see some compiling lines flowing by! :)
But after a minute or two I got a compile error in qtjava;
QPointArray.cpp:279: error: cast from 'QPoint*' to 'jint' loses precision

I'm a little confused why there are qtjava/qtkde files in svn anyway; I
recall we autogenerate them to avoid version conflicts. And now I have a
version conflict...
*confused*

Anyone can shed some light on this?

[Richard Dale]

Hi Thomas

Post by Thomas Zander
Since a few weeks I have been blessed with a new laptop, which is fast
enough to try to get kdebindings (3.5 branch) to compile again. (I never
actually got it working at all).
After finding out that unsermake is unsupported I tried the old make stuff
in a src==builddir. I.e. no features.

Yes, I don't know why we have to switch to unsermake. kdebindings has always
been difficult to build, and now it's harder.

Post by Thomas Zander
I actually got some to see some compiling lines flowing by! :)
But after a minute or two I got a compile error in qtjava;
QPointArray.cpp:279: error: cast from 'QPoint*' to 'jint' loses precision

I get a warning for that source on line 229 - is that the same one? The code
for that method is hard wired into kalyptus as a special case, and so it
should be easy to fix.

Post by Thomas Zander
I'm a little confused why there are qtjava/qtkde files in svn anyway; I
recall we autogenerate them to avoid version conflicts. And now I have a
version conflict...
*confused*
Anyone can shed some light on this?

Yes, the code shouldn't be in the svn, but I've never had the time to do it -
a week of autohell or whatever. This version of the bindings was supposed to
be a temporary measure before I got round to doing some using Dynamic Proxies
and the Smoke library instead of JNI. But I haven't the time to switch to the
proxy version, maybe not until KDE 4 now.

-- Richard