# ChangeLog for dev-java/java-gnome
# Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/java-gnome/ChangeLog,v 1.20 2004/09/01 08:47:37 axxo Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/java-gnome/ChangeLog,v 1.21 2004/12/28 12:54:11 axxo Exp $
+
+* java-gnome-2.8.2-r3 (27 Dec 2004)
+
+ 27 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +java-gnome-2.8.2-r3.ebuild:
+ Bump to pick up upstream maint releases to libgtk-java and libglade-java
+
+* java-gnome-2.8.2-r2 (24 Dec 2004)
+
+ 24 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +java-gnome-2.8.2-r2.ebuild java-gnome-2.8.2-r1.ebuild:
+ Bump to pick up the libglade bugfix
+
+* java-gnome-2.8.2-r1 (17 Nov 2004)
+
+ 17 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com> java-gnome-2.8.2-r1.ebuild:
+ Upped dependencies on lib*java for their small ebuild improvements.
+
+ 10 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com> java-gnome-2.8.2.ebuild:
+ The java-gnome metapackage now generates JavaDoc for the whole java-gnome
+ suite. There's no point in creating disconnected bits of JavaDoc as anyone
+ developing against it needs the whole pile together.
+
+* java-gnome-2.8.2 (08 Nov 2004)
+
+ 08 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
+ MAJOR CHANGE.
+
+ What used to be java-gnome is now multiplexed into various modular
+ subcomponents. Upstream CVS was all re-arranged, and now they release a tarball
+ for each piece. This ebuild is now [only] a meta package which in turn depends
+ on the various individual libraries (libgtk-java, libglade-java, etc) which
+ make up the java-gnome suite.
+
+ Note that this is marked as blocking older java-gnome versions. The
+ The risk of naming collisions between java-gnome-2.6 and lib*-java-2.8*
+ is too high.
01 Sep 2004; Thomas Matthijs <axxo@gentoo.org> java-gnome-2.6.0.1-r1.ebuild:
update depends, closes 62437
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
MD5 90e3c444913def0075d911ad5e608414 java-gnome-0.8.3.ebuild 1719
+MD5 2b28c728ffa6bb77a09504df167b1bab java-gnome-2.8.2-r3.ebuild 3657
MD5 3eec01d17dab5462a2e5ee8018184c21 java-gnome-2.6.0.1-r1.ebuild 2764
MD5 f0202da9a3b2534ea914ae6c8b3fc3a4 java-gnome-2.6.0.1.ebuild 2697
-MD5 9607337b773d7b890d62e0b15ee62345 ChangeLog 3237
-MD5 a6ec7d7724fbd068ffb39b5be56134ed metadata.xml 157
+MD5 774c4a70e92ff04de744ae52dd0b2006 ChangeLog 4762
+MD5 90071431b860e3979d0039f28b71fba2 metadata.xml 1217
+MD5 9bbbad31b6de0a61a701c6faf12e29ab java-gnome-2.8.2-r2.ebuild 3655
MD5 95eae7ebf2d8a9d2443cb7f138aab94b files/java-gnome-0.8.3-gentoo.diff 3998
+MD5 d41d8cd98f00b204e9800998ecf8427e files/digest-java-gnome-2.8.2-r2 0
+MD5 d41d8cd98f00b204e9800998ecf8427e files/digest-java-gnome-2.8.2-r3 0
MD5 3b0e994589f54485c4c6f43618005bc7 files/gentoo-java-gnome-2.6.0.1.patch 3574
MD5 a26e989caf78aa69cbd7e1572f1f6d35 files/digest-java-gnome-2.6.0.1 72
MD5 a26e989caf78aa69cbd7e1572f1f6d35 files/digest-java-gnome-2.6.0.1-r1 72
MD5 d0548db82a1916704411084a9a019f05 files/digest-java-gnome-0.8.3 70
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1.2.6 (GNU/Linux)
-
-iD8DBQFBNYzv/rLF9B432nYRAmdqAKCy495ul1fSylmuMbg8oaDGJESb8wCgkG8Y
-6o7KspGQZPupctQY/RlCRTk=
-=vUaL
------END PGP SIGNATURE-----
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/java-gnome/java-gnome-2.8.2-r2.ebuild,v 1.1 2004/12/28 12:54:11 axxo Exp $
+
+inherit eutils
+
+DESCRIPTION="A meta package for all the bindings libraries necessary to write GNOME/GTK applicatons in Java"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+DEPEND="!<dev-java/java-gnome-2.8
+ >=dev-java/libgtk-java-2.4.6-r2
+ >=dev-java/libgnome-java-2.8.2-r1
+ >=dev-java/libgconf-java-2.8.2
+ >=dev-java/libglade-java-2.8.2-r1
+ doc? ( >=virtual/jdk-1.2 )"
+
+SLOT="2.8"
+LICENSE="as-is"
+KEYWORDS="~x86 ~ppc"
+IUSE="doc"
+
+pkg_setup() {
+
+ einfo ""
+ einfo "The java-gnome project has made considerably changes to its internal"
+ einfo "structure. Instead of one monolithic java-gnome package, there are"
+ einfo "now indiviudal builds for libgtk-java, libgnome-java, libglade-java, etc"
+ einfo ""
+ einfo "This java-gnome ebuild is now a meta package which simply depends on"
+ einfo "the various new ebuilds"
+ einfo ""
+ ewarn "While this ebuild is slotted 2.8, it is marked as being blocked by"
+ ewarn "the presence of older versions of java-gnome if they exist on your"
+ ewarn "system. Not only were the 2.6 bindings really buggy, but with the"
+ ewarn "major re-organization of this package into modular pieces, the"
+ ewarn "risk of library and/or jar naming collisions is too high."
+ einfo ""
+ einfo "By the time you see this message, the above issues have been"
+ einfo "resolved (ie the new lib*-java packages will all be merged,"
+ einfo "and any old java-gnome packages are now removed)."
+ einfo ""
+}
+
+src_compile() {
+ use doc || return
+
+ #
+ # Upstream's reorg led to a total mess with the generated Javadoc.
+ # This attempts to replace it for the time being, creating Javadoc
+ # for all the java-gnome libraries at one go (which makes way more sense
+ # than one per library scattered all over)
+ #
+
+ cd ${WORKDIR}
+
+ # Yes, this is terrible hard coding. I'd welcome someone telling me
+ # how to do this better.
+
+ unzip -o -q /usr/share/libgtk-java-2.4/src/libgtk-java-2.4.6.src.zip -d java
+ unzip -o -q /usr/share/libgnome-java-2.8/src/libgnome-java-2.8.2.src.zip -d java
+ unzip -o -q /usr/share/libgconf-java-2.8/src/libgconf-java-2.8.2.src.zip -d java
+ unzip -o -q /usr/share/libglade-java-2.8/src/libglade-java-2.8.2.src.zip -d java
+
+ javadoc \
+ -public -use -version -author \
+ -windowtitle "java-gnome ${PV} API Reference" \
+ -doctitle "API reference for <B><TT>java-gnome</TT></B>, version ${PV}" \
+ -d api \
+ -sourcepath java \
+ org.gnu.glib \
+ org.gnu.pango \
+ org.gnu.atk \
+ org.gnu.gdk \
+ org.gnu.gtk \
+ org.gnu.gtk.event \
+ org.gnu.gnome \
+ org.gnu.gnome.event \
+ org.gnu.glade \
+ org.gnu.gconf
+}
+
+src_install() {
+ einfo "creating symlinks for convenience and backwards compatability"
+
+ #
+ # This is just here for convenience and for legacy compatability.
+ #
+ # This isn't meant to be Java policy compliant. There is no
+ # package.env file for this ebuild because the individual libraries
+ # it depends on all have proper package.env (which this uses, in fact).
+ #
+
+ mkdir -p ${D}/usr/share/java-gnome/lib
+ cd ${D}/usr/share/java-gnome/lib
+
+ gtk_jar=`java-config -p libgtk-java-2.4`
+ ln -s $gtk_jar `basename $gtk_jar`
+
+ gnome_jar=`java-config -p libgnome-java-2.8`
+ ln -s $gnome_jar `basename $gnome_jar`
+
+ glade_jar=`java-config -p libglade-java-2.8`
+ ln -s $glade_jar `basename $glade_jar`
+
+ gconf_jar=`java-config -p libgconf-java-2.8`
+ ln -s $gconf_jar `basename $gconf_jar`
+
+
+ use doc || return
+
+ mkdir -p ${D}/usr/share/doc/${PF}
+ mv ${WORKDIR}/api ${D}/usr/share/doc/${PF}
+}
+
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/java-gnome/java-gnome-2.8.2-r3.ebuild,v 1.1 2004/12/28 12:54:11 axxo Exp $
+
+inherit eutils
+
+DESCRIPTION="A meta package for all the bindings libraries necessary to write GNOME/GTK applicatons in Java"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+DEPEND="!<dev-java/java-gnome-2.8
+ >=dev-java/libgtk-java-2.4.7.2
+ >=dev-java/libgnome-java-2.8.2-r1
+ >=dev-java/libgconf-java-2.8.2
+ >=dev-java/libglade-java-2.8.2.2
+ doc? ( >=virtual/jdk-1.2 )"
+
+SLOT="2.8"
+LICENSE="as-is"
+KEYWORDS="~x86 ~ppc"
+IUSE="doc"
+
+pkg_setup() {
+
+ einfo ""
+ einfo "The java-gnome project has made considerably changes to its internal"
+ einfo "structure. Instead of one monolithic java-gnome package, there are"
+ einfo "now indiviudal builds for libgtk-java, libgnome-java, libglade-java, etc"
+ einfo ""
+ einfo "This java-gnome ebuild is now a meta package which simply depends on"
+ einfo "the various new ebuilds"
+ einfo ""
+ ewarn "While this ebuild is slotted 2.8, it is marked as being blocked by"
+ ewarn "the presence of older versions of java-gnome if they exist on your"
+ ewarn "system. Not only were the 2.6 bindings really buggy, but with the"
+ ewarn "major re-organization of this package into modular pieces, the"
+ ewarn "risk of library and/or jar naming collisions is too high."
+ einfo ""
+ einfo "By the time you see this message, the above issues have been"
+ einfo "resolved (ie the new lib*-java packages will all be merged,"
+ einfo "and any old java-gnome packages are now removed)."
+ einfo ""
+}
+
+src_compile() {
+ use doc || return
+
+ #
+ # Upstream's reorg led to a total mess with the generated Javadoc.
+ # This attempts to replace it for the time being, creating Javadoc
+ # for all the java-gnome libraries at one go (which makes way more sense
+ # than one per library scattered all over)
+ #
+
+ cd ${WORKDIR}
+
+ # Yes, this is terrible hard coding. I'd welcome someone telling me
+ # how to do this better.
+
+ unzip -o -q /usr/share/libgtk-java-2.4/src/libgtk-java-2.4.7.2.src.zip -d java
+ unzip -o -q /usr/share/libgnome-java-2.8/src/libgnome-java-2.8.2.src.zip -d java
+ unzip -o -q /usr/share/libgconf-java-2.8/src/libgconf-java-2.8.2.src.zip -d java
+ unzip -o -q /usr/share/libglade-java-2.8/src/libglade-java-2.8.2.2.src.zip -d java
+
+ javadoc \
+ -public -use -version -author \
+ -windowtitle "java-gnome ${PV} API Reference" \
+ -doctitle "API reference for <B><TT>java-gnome</TT></B>, version ${PV}" \
+ -d api \
+ -sourcepath java \
+ org.gnu.glib \
+ org.gnu.pango \
+ org.gnu.atk \
+ org.gnu.gdk \
+ org.gnu.gtk \
+ org.gnu.gtk.event \
+ org.gnu.gnome \
+ org.gnu.gnome.event \
+ org.gnu.glade \
+ org.gnu.gconf
+}
+
+src_install() {
+ einfo "creating symlinks for convenience and backwards compatability"
+
+ #
+ # This is just here for convenience and for legacy compatability.
+ #
+ # This isn't meant to be Java policy compliant. There is no
+ # package.env file for this ebuild because the individual libraries
+ # it depends on all have proper package.env (which this uses, in fact).
+ #
+
+ mkdir -p ${D}/usr/share/java-gnome/lib
+ cd ${D}/usr/share/java-gnome/lib
+
+ gtk_jar=`java-config -p libgtk-java-2.4`
+ ln -s $gtk_jar `basename $gtk_jar`
+
+ gnome_jar=`java-config -p libgnome-java-2.8`
+ ln -s $gnome_jar `basename $gnome_jar`
+
+ glade_jar=`java-config -p libglade-java-2.8`
+ ln -s $glade_jar `basename $glade_jar`
+
+ gconf_jar=`java-config -p libgconf-java-2.8`
+ ln -s $gconf_jar `basename $gconf_jar`
+
+
+ use doc || return
+
+ mkdir -p ${D}/usr/share/doc/${PF}
+ mv ${WORKDIR}/api ${D}/usr/share/doc/${PF}
+}
+
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
-<herd>java</herd>
+ <herd>java</herd>
+ <maintainer>
+ <email>andrew@operationaldynamics.com</email>
+ <name>Andrew Cowie</name>
+ </maintainer>
+ <longdescription>
+ An elegant set of language bindings to allow you to write
+ native GNOME/GTK applications in Java. Works with both
+ traditional Java VMs and also with GCJ, allowing the creation
+ of native Linux executable binaries.
+
+ These libraries all come from the java-gnome project, which in
+ turn is part of the official suite of GNOME language bindings.
+
+ As of java-gnome 2.8, the previously monolithic package was
+ split into numerous individual libraries to allow more
+ modular use. Those libraries are libgtk-java, libgnome-java,
+ libgconf-java, libglade-java, etc.
+
+ This ebuild is a meta package which simply depends on the
+ various libraries which make up the complete java-gnome suite.
+
+ In all likelihood (especially if you're developing apps) this
+ is what you want to emerge.
+ </longdescription>
</pkgmetadata>
# ChangeLog for dev-java/libglade-java
# Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/ChangeLog,v 1.3 2004/12/21 20:15:30 karltk Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/ChangeLog,v 1.4 2004/12/28 12:56:02 axxo Exp $
+
+* libglade-java-2.8.2.2 (27 Dec 2004)
+
+ 27 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +libglade-java-2.8.2.2.ebuild:
+ New upstream with the fix below. Note that 2.8.2.1 had an internal version
+ number glitch
+
+* libglade-java-2.8.2-r1 (24 Dec 2004)
+
+ 24 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +libglade-java-2.8.2-r1.ebuild, -libglade-java-2.8.2.ebuild:
+ Nasty little bug with respect to signal connection. Luckily, simple fix.
+ See gnome.org bug #161190 which in turn is based on Red Hat bug #141713. This
+ will go away very shortly if a new upstream is released (largely and only
+ containing this patch).
+
+ 18 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com> libglade-java-2.8.2.ebuild:
+ Marked stable on x86
+
+* libglade-java-2.8.2 (08 Nov 2004)
+
+ 08 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
+ New ebuild. What used to be java-gnome is now multiplexed into various modular
+ subcomponents. Upstream CVS was all re-arranged, and now there is a release
+ tarball for each piece. This is the Java binding for LibGlade.
* libglade-java-2.8.2 (04 Dec 2004)
New ebuild. What used to be java-gnome is now multiplexed into various modular
subcomponents. Upstream CVS was all re-arranged, and now there is a release
tarball for each piece. This is the Java binding for LibGlade.
-
-MD5 af8505b511150249c7a4362d44ad4d99 libglade-java-2.8.2.ebuild 3281
-MD5 e947694d041fc300319c4595b6515cd5 ChangeLog 663
-MD5 25131e29d5a6eb23196ff70fdf259706 metadata.xml 1306
+MD5 5f81dd012f8a55dbc7ce70adf9cf293e libglade-java-2.8.2-r1.ebuild 3181
+MD5 3750c810331e78e83726a9e34083a98e libglade-java-2.8.2.2.ebuild 3294
+MD5 f3a2f63406a8a4a51919c576191fdf65 libglade-java-2.8.2.ebuild 3291
+MD5 2b49f06517e29a5e87f4a8a84e3ea877 ChangeLog 1203
+MD5 d50086d74d4377e4f0a73922c949eac1 metadata.xml 1305
+MD5 eda99aeb347c072151e20c330b8cc3c4 files/digest-libglade-java-2.8.2-r1 71
+MD5 7ac5fbc0483956edf0634e70b501ce1a files/libglade-java-2.8.2_signal-connection-fix.patch 630
+MD5 c22ae14a58aed3c45a686a82e04094bb files/digest-libglade-java-2.8.2.2 73
MD5 eda99aeb347c072151e20c330b8cc3c4 files/digest-libglade-java-2.8.2 71
MD5 c068d53842b2d7d7efdca61acf5d72ca files/libglade-java-2.8.2_gentoo-PN-SLOT.patch 1190
--- /dev/null
+MD5 428aad7b148cb2e4d695a04593b52435 libglade-java-2.8.2.tar.bz2 31557
--- /dev/null
+MD5 ff3d2120538c1e0d1ef3f7f813dddbd7 libglade-java-2.8.2.2.tar.bz2 81449
--- /dev/null
+diff -u -r1.3 LibGlade.java.in
+--- libglade-java/src/java/org/gnu/glade/LibGlade.java.in 24 Oct 2004 12:19:55 -0000 1.3
++++ libglade-java/src/java/org/gnu/glade/LibGlade.java.in 24 Dec 2004 00:39:38 -0000
+@@ -88,8 +88,9 @@
+ /* When you call glade_xml_new_from_buffer, it looses
+ * information about what the glade file was, and later runs
+ * into issues if you try to instantiate anything that needs a
+- * path relative to that file for example, a GtkPibuf */
++ * path relative to that file for example, a GtkPixbuf */
+
++ this.owner = owner;
+ glade_xml_new(file, root);
+ glade_xml_signal_autoconnect_full();
+ }
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/libglade-java-2.8.2-r1.ebuild,v 1.1 2004/12/28 12:56:02 axxo Exp $
+
+#
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# other java libraries, it has its own [necessary] `make install` step.
+# As a result, this ebuild is VERY sensitive to the internal layout of the
+# upstream project. Because these issues are currently evolving upstream,
+# simply version bumping this ebuild is not likely to work but FAILURES WILL
+# BE VERY SUBTLE IF IT DOES NOT WORK.
+#
+
+inherit eutils gnome.org
+
+DESCRIPTION="Java bindings for [Lib]Glade (allows GNOME/GTK applications writen in Java to be generate their user interface based on Glade description files)"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+RDEPEND=">=gnome-base/libglade-2.3.6
+ >=dev-java/libgtk-java-2.4.6-r2
+ >=dev-java/libgnome-java-2.8.2-r1
+ >=virtual/jre-1.2"
+
+#
+# Unfortunately we need to run autogen to do the variable substitutions, so
+# regardless of whether or not there is an upstream ./configure [at time of
+# writing there isn't] we need to recreate it
+#
+
+DEPEND="${RDEPEND}
+ >=virtual/jdk-1.2
+ app-arch/zip"
+
+#
+# Critical that this match gtkapiversion
+#
+SLOT="2.8"
+LICENSE="LGPL-2.1"
+KEYWORDS="~x86 ~ppc"
+IUSE="gcj"
+
+src_unpack() {
+ unpack ${A}
+ cd ${S}
+ epatch ${FILESDIR}/libglade-java-2.8.2_gentoo-PN-SLOT.patch
+ epatch ${FILESDIR}/libglade-java-2.8.2_signal-connection-fix.patch
+}
+
+src_compile() {
+ local conf
+
+ use gcj || conf="${conf} --without-gcj-compile"
+
+ cd ${S}
+
+ #
+ # Ordinarily, moving things around post `make install` would do
+ # the trick, but there are paths hard coded in .pc files and in the
+ # `make install` step itself that need to be influenced.
+ #
+
+ ./autogen.sh \
+ --host=${CHOST} \
+ --prefix=/usr \
+ ${conf} || die "./configure failed"
+ make || die "compile failed"
+}
+
+src_install() {
+ # workaround Makefile bug not creating necessary parent directories
+ mkdir -p ${D}/usr/lib
+ mkdir -p ${D}/usr/share/java
+ mkdir -p ${D}/usr/lib/pkgconfig
+ mkdir -p ${D}/usr/share/doc/libglade${SLOT}-java
+
+ make prefix=${D}/usr install || die
+
+ # actually, at time of writing, there were no DOCUMENTS, but leave it here...
+ mv ${D}/usr/share/doc/libglade${SLOT}-java ${D}/usr/share/doc/${PF}
+
+ # the upstream install scatters things around a bit. The following cleans
+ # that up to make it policy compliant.
+
+ # I originally tried java-pkg_dojar here, but it has a few glitches
+ # like not copying symlinks as symlinks which makes a mess.
+
+ dodir /usr/share/${PN}-${SLOT}/lib
+ mv ${D}/usr/share/java/*.jar ${D}/usr/share/${PN}-${SLOT}/lib
+ rm -rf ${D}/usr/share/java
+
+ mkdir ${D}/usr/share/${PN}-${SLOT}/src
+ cd ${S}/src/java
+ zip -r ${D}/usr/share/${PN}-${SLOT}/src/libglade-java-${PV}.src.zip *
+
+ # again, with dojar misbehaving, better do to this manually for the
+ # time being. Yes, this is bad hard coding, but what in this ebuild isn't?
+
+ echo "DESCRIPTION=${DESCRIPTION}" \
+ > ${D}/usr/share/${PN}-${SLOT}/package.env
+
+ echo "CLASSPATH=/usr/share/${PN}-${SLOT}/lib/glade${SLOT}.jar" \
+ >> ${D}/usr/share/${PN}-${SLOT}/package.env
+}
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/libglade-java-2.8.2.2.ebuild,v 1.1 2004/12/28 12:56:02 axxo Exp $
+
+#
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# other java libraries, it has its own [necessary] `make install` step.
+# As a result, this ebuild is VERY sensitive to the internal layout of the
+# upstream project. Because these issues are currently evolving upstream,
+# simply version bumping this ebuild is not likely to work but FAILURES WILL
+# BE VERY SUBTLE IF IT DOES NOT WORK.
+#
+
+inherit eutils gnome.org
+
+DESCRIPTION="Java bindings for [Lib]Glade (allows GNOME/GTK applications writen in Java to be generate their user interface based on Glade description files)"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+RDEPEND=">=gnome-base/libglade-2.3.6
+ >=dev-java/libgtk-java-2.4.7.1
+ >=dev-java/libgnome-java-2.8.2-r1
+ >=virtual/jre-1.2"
+
+#
+# Unfortunately we need to run autogen to do the variable substitutions, so
+# regardless of whether or not there is an upstream ./configure [at time of
+# writing there isn't] we need to recreate it
+#
+
+DEPEND="${RDEPEND}
+ >=virtual/jdk-1.2
+ app-arch/zip
+ sys-devel/autoconf
+ sys-devel/automake"
+
+#
+# Critical that this match gtkapiversion
+#
+SLOT="2.8"
+LICENSE="LGPL-2.1"
+KEYWORDS="~x86 ~ppc"
+IUSE="gcj"
+
+src_unpack() {
+ unpack ${A}
+ cd ${S}
+ epatch ${FILESDIR}/libglade-java-2.8.2_gentoo-PN-SLOT.patch
+# fixed upstream, will remove next release.
+# epatch ${FILESDIR}/libglade-java-2.8.2_signal-connection-fix.patch
+ sed -i "s|^\(JAVA_INCLUDES = \)|\1 -I\${JDK_HOME}/include -I\${JDK_HOME}/include/linux/|" src/Makefile.in || die "sed failed"
+
+ rm -f ${S}/config.cache
+}
+
+src_compile() {
+ local conf
+
+ use gcj || conf="${conf} --without-gcj-compile"
+
+ cd ${S}
+
+ #
+ # Ordinarily, moving things around post `make install` would do
+ # the trick, but there are paths hard coded in .pc files and in the
+ # `make install` step itself that need to be influenced.
+ #
+
+ ./autogen.sh \
+ --host=${CHOST} \
+ --prefix=/usr \
+ ${conf} || die "./configure failed"
+ make || die "compile failed"
+}
+
+src_install() {
+ # workaround Makefile bug not creating necessary parent directories
+ mkdir -p ${D}/usr/lib
+ mkdir -p ${D}/usr/share/java
+ mkdir -p ${D}/usr/lib/pkgconfig
+ mkdir -p ${D}/usr/share/doc/libglade${SLOT}-java
+
+ make prefix=${D}/usr install || die
+
+ # actually, at time of writing, there were no DOCUMENTS, but leave it here...
+ mv ${D}/usr/share/doc/libglade${SLOT}-java ${D}/usr/share/doc/${PF}
+
+ # the upstream install scatters things around a bit. The following cleans
+ # that up to make it policy compliant.
+
+ # I originally tried java-pkg_dojar here, but it has a few glitches
+ # like not copying symlinks as symlinks which makes a mess.
+
+ dodir /usr/share/${PN}-${SLOT}/lib
+ mv ${D}/usr/share/java/*.jar ${D}/usr/share/${PN}-${SLOT}/lib
+ rm -rf ${D}/usr/share/java
+
+ mkdir ${D}/usr/share/${PN}-${SLOT}/src
+ cd ${S}/src/java
+ zip -r ${D}/usr/share/${PN}-${SLOT}/src/libglade-java-${PV}.src.zip *
+
+ # again, with dojar misbehaving, better do to this manually for the
+ # time being. Yes, this is bad hard coding, but what in this ebuild isn't?
+
+ echo "DESCRIPTION=${DESCRIPTION}" \
+ > ${D}/usr/share/${PN}-${SLOT}/package.env
+
+ echo "CLASSPATH=/usr/share/${PN}-${SLOT}/lib/glade${SLOT}.jar" \
+ >> ${D}/usr/share/${PN}-${SLOT}/package.env
+}
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/libglade-java-2.8.2.ebuild,v 1.1 2004/12/04 13:42:25 karltk Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libglade-java/libglade-java-2.8.2.ebuild,v 1.2 2004/12/28 12:56:02 axxo Exp $
#
-# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
-# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
# other java libraries, it has its own [necessary] `make install` step.
# As a result, this ebuild is VERY sensitive to the internal layout of the
# upstream project. Because these issues are currently evolving upstream,
# simply version bumping this ebuild is not likely to work but FAILURES WILL
# BE VERY SUBTLE IF IT DOESN NOT WORK.
-#
+#
inherit eutils gnome.org
>=virtual/jre-1.2"
#
-# Unfortunately we need to run autogen to do the variable substitutions, so
+# Unfortunately we need to run autogen to do the variable substitutions, so
# regardless of whether or not there is an upstream ./configure [at time of
# writing there isn't] we need to recreate it
#
cd ${S}
#
- # Ordinarily, moving things around post `make install` would do
+ # Ordinarily, moving things around post `make install` would do
# the trick, but there are paths hard coded in .pc files and in the
# `make install` step itself that need to be influenced.
#
--host=${CHOST} \
--prefix=/usr \
${conf} || die "./configure failed"
- make || die
+ make || die "compile failed"
}
src_install() {
# the upstream install scatters things around a bit. The following cleans
# that up to make it policy compliant.
- # I originally tried java-pkg_dojar here, but it has a few glitches
+ # I originally tried java-pkg_dojar here, but it has a few glitches
# like not copying symlinks as symlinks which makes a mess.
dodir /usr/share/${PN}-${SLOT}/lib
cd ${S}/src/java
zip -r ${D}/usr/share/${PN}-${SLOT}/src/libglade-java-${PV}.src.zip *
- # again, with dojar misbehaving, better do to this manually for the
+ # again, with dojar misbehaving, better do to this manually for the
# time being. Yes, this is bad hard coding, but what in this ebuild isn't?
# karltk: Missing generation of dependencies, should be fixed.
<email>andrew@operationaldynamics.com</email>
<name>Andrew Cowie</name>
</maintainer>
-
<longdescription>
An elegant set of language bindings to allow you to write
native GNOME applications in Java. Works with both traditional
# ChangeLog for dev-java/libgnome-java
# Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libgnome-java/ChangeLog,v 1.3 2004/12/21 20:31:02 karltk Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgnome-java/ChangeLog,v 1.4 2004/12/28 12:56:34 axxo Exp $
+* libgnome-java-2.8.2-r1 (17 Nov 2004)
+
+ 17 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com> +libgnome-java-2.8.2-r1:
+ Added libgnomeui to DEPENDS
+
+* libgnome-java-2.8.2 (08 Nov 2004)
+
+ 08 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
+ New ebuild. What used to be java-gnome is now multiplexed into various modular
+ subcomponents. Upstream CVS was all re-arranged, and now there is a release
+ tarball for each piece. This ebuild is the Java binding around the core GNOME
+ libraries.
+
*libgnome-java-2.8.2 (22 Nov 2004)
22 Nov 2004; Karl Trygve Kalleberg <karltk@gentoo.org> +metadata.xml,
+libgnome-java-2.8.2.ebuild:
Initial import. Fixes #70560.
- 08 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>
+ 08 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
New ebuild. What used to be java-gnome is now multiplexed into various modular
subcomponents. Upstream CVS was all re-arranged, and now there is a release
tarball for each piece. This ebuild is the Java binding around the core GNOME
libraries.
-
-MD5 9c530d6f88d9e2d9ebeaa22a4298c072 libgnome-java-2.8.2.ebuild 3201
-MD5 1f56da87e33bba4b9909e01805610ae2 ChangeLog 754
+MD5 a1af204707f4602d854d8b17ee5cd33c libgnome-java-2.8.2-r1.ebuild 3098
+MD5 c659fe24d8a6c0559037864bcc82c52a libgnome-java-2.8.2.ebuild 3211
+MD5 e92ad1645f76ffe44d6a12ed4e6f96d4 ChangeLog 1264
MD5 de0a216d1797f18db9dc83e5aedee360 metadata.xml 1002
+MD5 a8a8cdd7ec44ae7402032003fe1bb7ab files/digest-libgnome-java-2.8.2-r1 72
MD5 b5f8aad83ed35026438574e04a3122ac files/libgnome-java-2.8.2_gentoo-PN-SLOT.patch 1310
MD5 a8a8cdd7ec44ae7402032003fe1bb7ab files/digest-libgnome-java-2.8.2 72
--- /dev/null
+MD5 3fa03e9809f032540388b43dbf0cf582 libgnome-java-2.8.2.tar.bz2 126393
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgnome-java/libgnome-java-2.8.2-r1.ebuild,v 1.1 2004/12/28 12:56:34 axxo Exp $
+
+#
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# other java libraries, it has its own [necessary] `make install` step.
+# As a result, this ebuild is VERY sensitive to the internal layout of the
+# upstream project. Because these issues are currently evolving upstream,
+# simply version bumping this ebuild is not likely to work but FAILURES WILL
+# BE VERY SUBTLE IF IT DOES NOT WORK.
+#
+
+inherit eutils gnome.org
+
+DESCRIPTION="Java bindings for the core GNOME libraries (allow GNOME/GTK applications to be written in Java)"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+RDEPEND=">=gnome-base/libgnome-2.8.0
+ >=gnome-base/libgnomeui-2.8.0
+ >=dev-java/libgtk-java-2.4.6-r1
+ >=virtual/jre-1.2"
+
+#
+# Unfortunately we need to run autogen to do the variable substitutions, so
+# regardless of whether or not there is an upstream ./configure [at time of
+# writing there isn't] we need to recreate it
+#
+
+DEPEND="${RDEPEND}
+ >=virtual/jdk-1.2
+ app-arch/zip
+ sys-devel/autoconf
+ sys-devel/automake"
+
+#
+# Critical that this match gtkapiversion
+#
+SLOT="2.8"
+LICENSE="LGPL-2.1"
+KEYWORDS="~x86 ~ppc"
+IUSE="gcj"
+
+src_unpack() {
+ unpack ${A}
+ cd ${S}
+ epatch ${FILESDIR}/libgnome-java-2.8.2_gentoo-PN-SLOT.patch
+ sed -i "s|^\(JAVA_INCLUDES = \)|\1 -I\${JDK_HOME}/include -I\${JDK_HOME}/include/linux/|" src/Makefile.in || die "sed failed"
+}
+
+src_compile() {
+ local conf
+
+ use gcj || conf="${conf} --without-gcj-compile"
+
+ cd ${S}
+
+ #
+ # Ordinarily, moving things around post `make install` would do
+ # the trick, but there are paths hard coded in .pc files and in the
+ # `make install` step itself that need to be influenced.
+ #
+
+ ./autogen.sh \
+ --host=${CHOST} \
+ --prefix=/usr \
+ ${conf} || die "./configure failed"
+ make || die "compile failed"
+}
+
+src_install() {
+ # workaround Makefile bug not creating necessary parent directories
+ mkdir -p ${D}/usr/lib
+ mkdir -p ${D}/usr/share/java
+ mkdir -p ${D}/usr/lib/pkgconfig
+ mkdir -p ${D}/usr/share/doc/libgnome${SLOT}-java
+
+ make prefix=${D}/usr install || die
+
+ # actually, at time of writing, there were no DOCUMENTS, but leave it here...
+ mv ${D}/usr/share/doc/libgnome${SLOT}-java ${D}/usr/share/doc/${PF}
+
+ # the upstream install scatters things around a bit. The following cleans
+ # that up to make it policy compliant.
+
+ # I originally tried java-pkg_dojar here, but it has a few glitches
+ # like not copying symlinks as symlinks which makes a mess.
+
+ dodir /usr/share/${PN}-${SLOT}/lib
+ mv ${D}/usr/share/java/*.jar ${D}/usr/share/${PN}-${SLOT}/lib
+ rm -rf ${D}/usr/share/java
+
+ mkdir ${D}/usr/share/${PN}-${SLOT}/src
+ cd ${S}/src/java
+ zip -r ${D}/usr/share/${PN}-${SLOT}/src/libgnome-java-${PV}.src.zip *
+
+ # again, with dojar misbehaving, better do to this manually for the
+ # time being. Yes, this is bad hard coding, but what in this ebuild isn't?
+
+ echo "DESCRIPTION=${DESCRIPTION}" \
+ > ${D}/usr/share/${PN}-${SLOT}/package.env
+
+ echo "CLASSPATH=/usr/share/${PN}-${SLOT}/lib/gnome${SLOT}.jar" \
+ >> ${D}/usr/share/${PN}-${SLOT}/package.env
+}
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libgnome-java/libgnome-java-2.8.2.ebuild,v 1.1 2004/11/22 00:22:20 karltk Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgnome-java/libgnome-java-2.8.2.ebuild,v 1.2 2004/12/28 12:56:34 axxo Exp $
#
-# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
-# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
# other java libraries, it has its own [necessary] `make install` step.
# As a result, this ebuild is VERY sensitive to the internal layout of the
# upstream project. Because these issues are currently evolving upstream,
# simply version bumping this ebuild is not likely to work but FAILURES WILL
# BE VERY SUBTLE IF IT DOESN NOT WORK.
-#
+#
inherit eutils gnome.org
>=virtual/jre-1.2"
#
-# Unfortunately we need to run autogen to do the variable substitutions, so
+# Unfortunately we need to run autogen to do the variable substitutions, so
# regardless of whether or not there is an upstream ./configure [at time of
# writing there isn't] we need to recreate it
#
cd ${S}
#
- # Ordinarily, moving things around post `make install` would do
+ # Ordinarily, moving things around post `make install` would do
# the trick, but there are paths hard coded in .pc files and in the
# `make install` step itself that need to be influenced.
#
--host=${CHOST} \
--prefix=/usr \
${conf} || die "./configure failed"
- make || die
+ make || die "compile failed"
}
src_install() {
# the upstream install scatters things around a bit. The following cleans
# that up to make it policy compliant.
- # I originally tried java-pkg_dojar here, but it has a few glitches
+ # I originally tried java-pkg_dojar here, but it has a few glitches
# like not copying symlinks as symlinks which makes a mess.
dodir /usr/share/${PN}-${SLOT}/lib
cd ${S}/src/java
zip -r ${D}/usr/share/${PN}-${SLOT}/src/libgnome-java-${PV}.src.zip *
- # again, with dojar misbehaving, better do to this manually for the
+ # again, with dojar misbehaving, better do to this manually for the
# time being. Yes, this is bad hard coding, but what in this ebuild isn't?
echo "DESCRIPTION=${DESCRIPTION}" \
# ChangeLog for dev-java/libgtk-java
# Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/ChangeLog,v 1.3 2004/12/23 12:14:06 karltk Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/ChangeLog,v 1.4 2004/12/28 12:57:07 axxo Exp $
+
+* libgtk-java-2.4.7.2 (27 Dec 2004)
+
+ 27 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +libgtk-java-2.4.7.2.ebuild:
+ Upstream stable maintenance release. Note that 2.4.7 had a bug which
+ prevented it from building, and that 2.4.7.1 had its internal version numbers
+ wrong.
+
+* libgtk-java-2.4.6-r2 (24 Dec 2004)
+
+ 24 Dec 2004; Andrew Cowie <andrew@operationaldynamics.com> +libgtk-java-2.4.6-r2.ebuild,
+ -libgtk-java-2.4.6-r1.ebuild:
+ Version bump to ensure pickup of Thomas's patch.
+
+ 29 Nov 2004; Thomas Matthijs <axxo@gentoo.org> +files/libgtk-java-2.4.6_find_jni.patch,
+ libgtk-java-2.4.6-r1.ebuild:
+ added a patch to set JAVA_INCLUDES when not using gcj, so it can find jni.h
+ & familiy, #72128
+
+* libgtk-java-2.4.6-r1 (15 Nov 2004)
+
+ 15 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com> +libgtk-java-2.4.6-r1.ebuild:
+ Dependency on docbook-sgml-utils discovered by karltk; investigation showed
+ it to be highly unnecessary and an artifact of some (currently) unused cruft
+ in the documentation. Fixed by patching the java-gnome autoconf macros to
+ remove the path check for docbook2html.
+
+* libgtk-java-2.4.6 (07 Nov 2004)
+
+ 07 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
+ New ebuild. What used to be java-gnome is now multiplexed into various modular
+ subcomponents. Upstream CVS was all re-arranged, and now there is a release
+ tarball for each piece. This ebuild is the java binding around the core GTK
+ libraries (and is the only one of the new pieces which doesn't need the rest of
+ GNOME installed).
29 Nov 2004; Thomas Matthijs <axxo@gentoo.org>
+files/libgtk-java-2.4.6_find_jni.patch, libgtk-java-2.4.6-r1.ebuild:
*libgtk-java-2.4.6 (07 Nov 2004)
- 07 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>
+ 07 Nov 2004; Andrew Cowie <andrew@operationaldynamics.com>:
New ebuild. What used to be java-gnome is now multiplexed into various modular
subcomponents. Upstream CVS was all re-arranged, and now there is a release
tarball for each piece. This ebuild is the java binding around the core GTK
libraries (and is the only one of the new pieces which doesn't need the rest of
GNOME installed).
-
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-MD5 f238bbfcec2bfc89580dc1cc6ad94395 libgtk-java-2.4.6-r1.ebuild 3032
-MD5 ed4e8335ae855378eddf205b2f92d50c ChangeLog 1338
+MD5 64418c0f092b6abe94d34cb91b1b1764 libgtk-java-2.4.6-r2.ebuild 3043
+MD5 fc7a7c3173bc071cbedcc7e93630bf69 libgtk-java-2.4.7.2.ebuild 3344
+MD5 ecd83955c10abfb7302368afd32eacb4 libgtk-java-2.4.6-r1.ebuild 3007
+MD5 ea053cb7f019ae21f4881feb4323aeb5 ChangeLog 1684
MD5 23e70539fce4ef96d51e3043420acb8c metadata.xml 975
MD5 d5868ac77f6fa3fcf16ec100095cb0af files/digest-libgtk-java-2.4.6-r1 70
+MD5 d5868ac77f6fa3fcf16ec100095cb0af files/digest-libgtk-java-2.4.6-r2 70
MD5 1defc6f20e4684f13955e28a28e47e1f files/libgtk-java-2.4.6_install-doc.patch 740
MD5 1f2599c8fd250432f6e6b43d598e75db files/libgtk-java-2.4.6_gentoo-PN-SLOT.patch 2013
+MD5 44a67ac512c028ffef92f3a0ed1bc196 files/digest-libgtk-java-2.4.7.2 72
MD5 21907163f2b6597c520b7c1a4da20784 files/libgtk-java-2.4.6_find_jni.patch 369
MD5 40956547f4eb0b797359f67f6c6910bb files/libgtk-java-2.4.6_gcj-autoconf-macro-fix.patch 689
MD5 e8a6ddb689376b8e04d3bc41cca48253 files/libgtk-java-2.4.6_no-docbook-autoconf-macro.patch 394
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1.9.10 (GNU/Linux)
-
-iD8DBQFByww7I1lqEGTUzyQRAuHDAJwMajbvTZ8QbgosDHgNji5WRSMllACaAz4i
-44WjC2PAxGLJoMuh4HhObh4=
-=gZEm
------END PGP SIGNATURE-----
--- /dev/null
+MD5 3f4533073d2c51cb444d16ecf91e9d08 libgtk-java-2.4.6.tar.bz2 438133
--- /dev/null
+MD5 a91852eb5a0ff7b5487f55a17f2eb13b libgtk-java-2.4.7.2.tar.bz2 458397
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/libgtk-java-2.4.6-r1.ebuild,v 1.2 2004/11/29 15:35:33 axxo Exp $
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/libgtk-java-2.4.6-r1.ebuild,v 1.3 2004/12/28 12:57:07 axxo Exp $
#
# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
DEPEND="${RDEPEND}
>=virtual/jdk-1.2
- app-arch/zip
- sys-devel/autoconf
- sys-devel/automake"
+ app-arch/zip"
#
# Critical that this match gtkapiversion
--host=${CHOST} \
--prefix=/usr \
${conf} || die "./configure failed"
- make || die
+ make || die "compile failed"
}
src_install() {
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/libgtk-java-2.4.6-r2.ebuild,v 1.1 2004/12/28 12:57:07 axxo Exp $
+
+#
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# other java libraries, it has its own [necessary] `make install` step.
+# As a result, this ebuild is VERY sensitive to the internal layout of the
+# upstream project. Because these issues are currently evolving upstream,
+# simply version bumping this ebuild is not likely to work but FAILURES WILL
+# BE VERY SUBTLE IF IT DOES NOT WORK.
+#
+
+inherit eutils gnome.org
+
+DESCRIPTION="Java bindings for GTK libraries (allow GTK applications to be written in Java)"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+RDEPEND=">=x11-libs/gtk+-2.4
+ >=virtual/jre-1.2"
+
+#
+# Unfortunately we need to run autogen to do the variable substitutions, so
+# regardless of whether or not there is an upstream ./configure [at time of
+# writing there isn't] we need to recreate it
+#
+
+DEPEND="${RDEPEND}
+ >=virtual/jdk-1.2
+ app-arch/zip"
+
+#
+# Critical that this match gtkapiversion
+#
+SLOT="2.4"
+LICENSE="LGPL-2.1"
+KEYWORDS="~x86 ~ppc"
+IUSE="gcj"
+
+src_unpack() {
+ unpack ${A}
+ cd ${S}
+ epatch ${FILESDIR}/libgtk-java-2.4.6_gcj-autoconf-macro-fix.patch
+ epatch ${FILESDIR}/libgtk-java-2.4.6_gentoo-PN-SLOT.patch
+ epatch ${FILESDIR}/libgtk-java-2.4.6_install-doc.patch
+ epatch ${FILESDIR}/libgtk-java-2.4.6_no-docbook-autoconf-macro.patch
+ use gcj || epatch ${FILESDIR}/${P}_find_jni.patch
+}
+
+src_compile() {
+ local conf
+
+ use gcj || conf="${conf} --without-gcj-compile"
+
+ cd ${S}
+
+ #
+ # Ordinarily, moving things around post `make install` would do
+ # the trick, but there are paths hard coded in .pc files and in the
+ # `make install` step itself that need to be influenced.
+ #
+ # NOTE: THIS RELIES ON PORTAGE PASSING $PN AND $SLOT IN THE ENVIRONMENT
+ #
+
+ ./autogen.sh \
+ --host=${CHOST} \
+ --prefix=/usr \
+ ${conf} || die "./configure failed"
+ make || die "compile failed"
+}
+
+src_install() {
+ make prefix=${D}/usr install || die
+
+ mv ${D}/usr/share/doc/libgtk${SLOT}-java ${D}/usr/share/doc/${PF}
+
+ # the upstream install scatters things around a bit. The following cleans
+ # that up to make it policy compliant.
+
+ # I originally tried java-pkg_dojar here, but it has a few glitches
+ # like not copying symlinks as symlinks which makes a mess.
+
+ dodir /usr/share/${PN}-${SLOT}/lib
+ mv ${D}/usr/share/java/*.jar ${D}/usr/share/${PN}-${SLOT}/lib
+ rm -rf ${D}/usr/share/java
+
+ mkdir ${D}/usr/share/${PN}-${SLOT}/src
+ cd ${S}/src/java
+ zip -r ${D}/usr/share/${PN}-${SLOT}/src/libgtk-java-${PV}.src.zip *
+
+ # again, with dojar misbehaving, better do to this manually for the
+ # time being.
+
+ echo "DESCRIPTION=${DESCRIPTION}" \
+ > ${D}/usr/share/${PN}-${SLOT}/package.env
+
+ echo "CLASSPATH=/usr/share/${PN}-${SLOT}/lib/gtk${SLOT}.jar" \
+ >> ${D}/usr/share/${PN}-${SLOT}/package.env
+}
--- /dev/null
+# Copyright 1999-2004 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/dev-java/libgtk-java/libgtk-java-2.4.7.2.ebuild,v 1.1 2004/12/28 12:57:07 axxo Exp $
+
+#
+# WARNING: Because java-gnome is a set of bindings to native GNOME libraries,
+# it has, like any GNOME project, a massive autoconf setup, and unlike many
+# other java libraries, it has its own [necessary] `make install` step.
+# As a result, this ebuild is VERY sensitive to the internal layout of the
+# upstream project. Because these issues are currently evolving upstream,
+# simply version bumping this ebuild is not likely to work but FAILURES WILL
+# BE VERY SUBTLE IF IT DOES NOT WORK.
+#
+
+inherit eutils gnome.org
+
+DESCRIPTION="Java bindings for GTK libraries (allow GTK applications to be written in Java)"
+HOMEPAGE="http://java-gnome.sourceforge.net/"
+RDEPEND=">=x11-libs/gtk+-2.4
+ >=virtual/jre-1.2"
+
+#
+# Unfortunately we need to run autogen to do the variable substitutions, so
+# regardless of whether or not there is an upstream ./configure [at time of
+# writing there isn't] we need to recreate it
+#
+
+DEPEND="${RDEPEND}
+ >=virtual/jdk-1.2
+ app-arch/zip"
+
+#
+# Critical that this match gtkapiversion
+#
+SLOT="2.4"
+LICENSE="LGPL-2.1"
+KEYWORDS="~x86 ~ppc"
+IUSE="gcj"
+
+src_unpack() {
+ unpack ${A}
+ cd ${S}
+
+ # I know it's better to use ${P}, but I don't feel like duplicating
+ # the patch files for every bloody point release. I'll copy them at
+ # major version releases.
+
+# Fixed upstream, will remove next release
+# epatch ${FILESDIR}/libgtk-java-2.4.6_gcj-autoconf-macro-fix.patch
+
+ epatch ${FILESDIR}/libgtk-java-2.4.6_gentoo-PN-SLOT.patch
+ epatch ${FILESDIR}/libgtk-java-2.4.6_install-doc.patch
+ epatch ${FILESDIR}/libgtk-java-2.4.6_no-docbook-autoconf-macro.patch
+ use gcj || epatch ${FILESDIR}/libgtk-java-2.4.6_find_jni.patch
+
+ # Rediculous glitch from upstream's packaging.
+ rm -f ${S}/config.cache
+}
+
+src_compile() {
+ local conf
+
+ use gcj || conf="${conf} --without-gcj-compile"
+
+ cd ${S}
+
+ #
+ # Ordinarily, moving things around post `make install` would do
+ # the trick, but there are paths hard coded in .pc files and in the
+ # `make install` step itself that need to be influenced.
+ #
+ # NOTE: THIS RELIES ON PORTAGE PASSING $PN AND $SLOT IN THE ENVIRONMENT
+ #
+
+ ./autogen.sh \
+ --host=${CHOST} \
+ --prefix=/usr \
+ ${conf} || die "./configure failed"
+ make || die "compile failed"
+}
+
+src_install() {
+ make prefix=${D}/usr install || die
+
+ mv ${D}/usr/share/doc/libgtk${SLOT}-java ${D}/usr/share/doc/${PF}
+
+ # the upstream install scatters things around a bit. The following cleans
+ # that up to make it policy compliant.
+
+ # I originally tried java-pkg_dojar here, but it has a few glitches
+ # like not copying symlinks as symlinks which makes a mess.
+
+ dodir /usr/share/${PN}-${SLOT}/lib
+ mv ${D}/usr/share/java/*.jar ${D}/usr/share/${PN}-${SLOT}/lib
+ rm -rf ${D}/usr/share/java
+
+ mkdir ${D}/usr/share/${PN}-${SLOT}/src
+ cd ${S}/src/java
+ zip -r ${D}/usr/share/${PN}-${SLOT}/src/libgtk-java-${PV}.src.zip *
+
+ # again, with dojar misbehaving, better do to this manually for the
+ # time being.
+
+ echo "DESCRIPTION=${DESCRIPTION}" \
+ > ${D}/usr/share/${PN}-${SLOT}/package.env
+
+ echo "CLASSPATH=/usr/share/${PN}-${SLOT}/lib/gtk${SLOT}.jar" \
+ >> ${D}/usr/share/${PN}-${SLOT}/package.env
+}
projects / gentoo.git / commitdiff