the java-gnome bindings in portage are quite outdated, i tried to craft an ebuild with the help of Andrew Frederick Cowi PS: i have the gcj useflag set for gcc, Andrew Frederick Cowi told me its not necessary but the installation didnt work without it cheers Reproducible: Always
Created attachment 120709 [details] dev-java/java-gnome-4.0.2.ebuild ebuild for the latest java-gnome bindings
Created attachment 120793 [details] java-gnome-4.0.2.ebuild corrected doc useflag, added examples useflag, added java-pkg-functions
(In reply to comment #2) > Created an attachment (id=120793) [edit] > java-gnome-4.0.2.ebuild > > corrected doc useflag, added examples useflag, added java-pkg-functions > Thanks for the work so far. Here are my review comments: SRC_URI="mirror://gnome/sources/java-gnome/4.0/java-gnome-${PV}.tar.gz" use ${PN} for java-gnome and versionator.eclass to get 4.0 RDEPEND=">=dev-libs/glib-2.12.11 >=x11-libs/gtk+-2.10.12 >=gnome-base/libglade-2.6.0 >=gnome-base/libgnome-2.16.0" missing virtual/jre src_compile(){ ./configure --prefix=/usr make || die "Compilation of java-gnome failed" use emake why not econf? use doc && make doc failure in make would not result in die dodoc AUTHORS HACKING LICENCE NEWS README always install these files make install DESTDIR=${D} || die "Installation of java-gnome failed" java-pkg_regjar /usr/share/java/gtk-4.0.jar betelgeuse@pena ~ $ ls /usr/share/java/ ls: cannot access /usr/share/java/: No such file or directory Better to rm this file and java-pkg_dojar to install to the standard location. Nothing expects to find the jar in java/ so no reason to deviate from our default directory layout.
FEATURES=ccache is broken atm so should resolve that before going to the main tree. 12:45 < AfC> but we've more than enough time to fix this scenario in time for 4.0.3, 12:45 < AfC> and will do so 12:45 < AfC> Betelgeuse: and I thank you for uncovering the bug 12:46 < AfC> Maybe we'll merge the $(CCACHE) and $(CC) variables into one.
Created attachment 120862 [details] java-gnome-4.0.2.ebuild applied suggested fixes concerning the useflag doc and the java-pkg_dojar
We'll fix the ccache question in mainline and I'll post a patch you can use here. AfC
Created attachment 120872 [details] java-gnome-4.0.2.ebuild added source useflag
(In reply to comment #7) > Created an attachment (id=120872) [edit] > java-gnome-4.0.2.ebuild > > added source useflag > inherit eutils java-pkg-2 java-ant-2 The build system doesn't use ant as far as I know SRC_URI="mirror://gnome/sources/java-gnome/4.0/${PF}.tar.gz" Use get_version_component_range from versionator.eclass to get 4.0 RDEPEND=">=dev-libs/glib-2.12.11 >=x11-libs/gtk+-2.10.12 >=gnome-base/libglade-2.6.0 >=gnome-base/libgnome-2.16.0 virtual/jre" Needs to be >=virtual/jre-1.4 as >=virtual/jdk-1.4 builds to 1.4 bytecode.
1. No, ant is not used and therefore not required. 2. jre >= 1.4 is what I suggested to reporter. However, the build process carefully specifies -source 1.4 -target 1.4 to the compilers, so this is somewhat secondary. AfC
(In reply to comment #9) > 1. No, ant is not used and therefore not required. > > 2. jre >= 1.4 is what I suggested to reporter. However, the build process > carefully specifies -source 1.4 -target 1.4 to the compilers, so this is > somewhat secondary. > Specifying -source 1.4 -target 1.4 is exactly the reason >=virtual/jre-1.4 is needed as it means we have 1.4 bytecode. If you turn on JAVA_PKG_STRICT=1 in make.conf you will see that your eclass bytecode validation most likely fails unless you add the version.
Created attachment 120941 [details] java-gnome-4.0.2.ebuild thanks for ur advices, added versionator's functionality, removed ant's inheritage
(In reply to comment #11) > Created an attachment (id=120941) [edit] > java-gnome-4.0.2.ebuild > > thanks for ur advices, added versionator's functionality, removed ant's > inheritage > SRC_URI="mirror://gnome/sources/java-gnome/$(get_version_component_range 1-2)/${PF}.tar.gz" PF includes the -rX part which you will not find in upstream sources should use $PV instead. Still not using emake instead of make. No reason to upload a new upload a new ebuild for just these though as long as they are fixed by the one who will eventually commit this to Portage.
I tried to emerge this. But it failes within the sandbox. ./configure works fine outside. Check native compiler: - GNU gcc compiling doesn't work Any suggestions?
It might be FEATURES=ccache screwing up the definition of gcc. I haven't personally had time to look into why that might be a problem, though. AfC
*** Bug 188761 has been marked as a duplicate of this bug. ***
Problem reproduced and resolved. We are very aggressive about dereferencing symlinks for what are otherwise good reasons, but in the case of FEATURES=ccache, this causes /usr/lib/ccache/bin/gcc to be returned as /usr/bin/ccache (which is the _other_ way of invoking it, whereby it has to be used as a prefix for gcc, which is in turn how we _do_ use it normally if detected). I'll clean this up in upstream before 4.0.4, but in the mean time, I've attached a patch to kludge around it. I also touched up the ebuild originally submitted to this bug, and have attached it as java-gnome.4.0.3.ebuild. It uses the provided patch. There are a few minor points to think about, but we can discuss those online and before 4.0.4 comes along. For now, I hope that this will allow you to merge java-gnome to Portage. Thanks to all contributors and reporters. AfC Maintainer java-gnome
Created attachment 128483 [details, diff] files/4.0.3-ccache-workaround.patch
Created attachment 128484 [details] java-gnome-4.0.3.ebuild Upgraded ebuild to deal with current release of java-gnome, 4.0.3. AfC
(In reply to comment #18) > Created an attachment (id=128484) [edit] > java-gnome-4.0.3.ebuild > > Upgraded ebuild to deal with current release of java-gnome, 4.0.3. > > AfC > Added with the following changes: betelgeuse@pena /usr/portage/dev-java/java-gnome $ diff -u attachment.cgi\?id\=128484 java-gnome-4.0.3.ebuild --- attachment.cgi?id=128484 2007-08-18 19:08:41.000000000 +0300 +++ java-gnome-4.0.3.ebuild 2007-08-18 20:28:12.000000000 +0300 @@ -2,55 +2,48 @@ # Distributed under the terms of the GNU General Public License v2 # $Header: $ -inherit eutils java-pkg-2 versionator +JAVA_PKG_IUSE="doc examples source" + +inherit eutils versionator java-pkg-2 using JAVA_PKG_IUSE makes source proper dependencies for dosrc get pulled. DESCRIPTION="Java bindings for GTK and GNOME" HOMEPAGE="http://java-gnome.sourceforge.net/" -SRC_URI="mirror://gnome/sources/java-gnome/$(get_version_component_range 1-2)/${PF}.tar.bz2" +SRC_URI="mirror://gnome/sources/${PN}/$(get_version_component_range 1-2)/${P}.tar.bz2" LICENSE="GPL-2-with-linking-exception" SLOT="4.0" KEYWORDS="~x86" -IUSE="doc examples source" +IUSE="" RDEPEND=">=dev-libs/glib-2.12.13 >=x11-libs/gtk+-2.10.14 >=gnome-base/libglade-2.6.1 >=gnome-base/libgnome-2.18.0 + >=gnome-base/gnome-desktop-2.18.0 >=virtual/jre-1.4" did not merge for me without gnome-desktop installed -DEPEND="dev-lang/perl +DEPEND="${RDEPEND} dev-lang/python >=virtual/jdk-1.4" perl is part of the system target and as such not needed here src_compile() { + epatch "${FILESDIR}/4.0.3-ccache-workaround.patch" - epatch ${FILESDIR}/4.0.3-ccache-workaround.patch - ./configure --prefix=/usr || die make || die "Compilation of java-gnome failed" - + if use doc; then make doc || die "Making documentation failed" fi } quoting and trailing white space src_install(){ - - dodoc AUTHORS HACKING LICENCE NEWS README - - if use doc; then - java-pkg_dojavadoc doc/api - fi + java-pkg_doso tmp/*.so + java-pkg_dojar tmp/*.jar - use examples && java-pkg_doexamples tests/prototype + dodoc AUTHORS HACKING NEWS README || die + use doc && java-pkg_dojavadoc doc/api + use examples && java-pkg_doexamples tests/prototype use source && java-pkg_dosrc src/bindings/org - - make install DESTDIR=${D} || die "Installation of java-gnome failed" - - if [ -d ${D}/usr/share/java/ ]; then - rm -rf ${D}/usr/share/java - java-pkg_dojar tmp/gtk-4.0.jar - fi } Seemed simpler to just use our eclass functions to install the files. You would need to java-pkg_regso for the shared libraries any way so that java-config knows it needs a jni component.
