Housekeeping in Debian and Ubuntu

1 files changed, 0 insertions, 64 deletions

diff --git a/ubuntu/lucid_automake/kdebindings/debian/libqt3-java-kde3.README.Debian b/ubuntu/lucid_automake/kdebindings/debian/libqt3-java-kde3.README.Debian
deleted file mode 100644
index ea0beb81c..000000000
--- a/ubuntu/lucid_automake/kdebindings/debian/libqt3-java-kde3.README.Debian
+++ /dev/null
@@ -1,64 +0,0 @@
-Developing and using Qt based applications written in Java
-==========================================================
-
-This document explains how to develop and use Qt based programs
-written in Java.  This is what the Qt java bindings from the package
-libqt3-java are designed to accomplish.
-
-Firstly, the bindings should work with any java compiler and VM
-properly implementing the JNI interface, but they have only been
-tested with the GCJ compiler and GIJ interpreter from the GCC suite.
-Note that the bindings are not compiled to native code, using GCJ's
-unique capability to do this, they are simply compiled to .class
-files, and interpreted, in the classical Java manner.
-
-Secondly, when compiling and running apps using the Qt Java bindings,
-you need to add "/usr/share/java/qtjava.jar" to the CLASSPATH.  E.g.
-
-	export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:."
-	javac Whatever.java
-	java Whatever
-
-And, that's basically the hard part of it all.  For the rest,
-developing Qt Java apps is much like Qt C++ apps, except that working
-with slots is easier, and compiles may be faster as well.  The API
-should be completely similar to the Qt C++ API, so the standard Qt
-docs should translate pretty easily.  There are a lot of Qt Java usage
-examples in /usr/share/doc/libqt3-java/examples.
-
-If you're interested in developing KDE applications using Java, look
-at the libkde3-java package.
-
-
-Generating native executables
------------------------------
-
-It is also possible to produce native executables with the following gcj
-invocation:
-
-	export CLASSPATH="/usr/share/java/qtjava.jar:/usr/share/java:."
-	gcj -fjni Somefile.java /usr/share/java/qtjava.jar --main=Somefile
-	LD_LIBRARY_PATH=/usr/lib/jni ./a.out
-
-As this will compile the full qtjava.jar into native code, the resulting
-executable will be rather large. If you plan on having several of these
-executables, it may be worth creating a shared qtjava library, like
-this:
-
-	gcj -fjni -shared /usr/share/java/qtjava.jar -o libqtjava-shared.so
-
-And then, after you put libqtjava-shared.so in /usr/lib or similar, you
-can go like:
-
-	gcj -fjni Somefile.java --main=Somefile -lqtjava-shared
-	LD_LIBRARY_PATH=/usr/lib/jni ./a.out
-
-In the future, I'll investigate the possibility of shipping the
-qtjava-shared library in the Debian packages.
-
-Also, in order to avoid the necessity of setting the LD_LIBRARY_PATH
-environment variable, the option -Djava.library.path=/usr/lib/jni can be
-passed to the gcj invocation. There is, however, a bug [1] in gcj that
-prevents this from working, and it's only fixed in gcj-4.0.
-
-    [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18234