DEPEND=">=virtual/jdk-1.4 dev-java/sun-j2me-bin dev-java/ant-core" RDEPEND=">=virtual/jre-1.4" src_compile() { eant -Dgentoo.classpath=$(java-pkg_getjars sun-j2me-bin,ant-core) proguard } Also, sun-j2me-bin contains Linux-only ELFs, making proguard incompatible with Gentoo/FreeBSD.
Well, it's not there anymore, I suppose this is good :)
(In reply to comment #1) > Well, it's not there anymore, I suppose this is good :) > huh? betelgeuse@pena /usr/portage/dev-java/proguard $ grep sun-j2me-bin * proguard-3.8.ebuild: dev-java/sun-j2me-bin proguard-3.8.ebuild: eant -Dgentoo.classpath=$(java-pkg_getjars sun-j2me-bin,ant-core) proguard
proguard-4.0_beta5 uses 'j2me' use flag which puts dev-java/sun-j2me-bin in deps so it is now optional instead of being mandatory, so not in a tree yet but solved
This is not a problem as of 4.1 as well. Its not in the tree either.
Anyway we now have cldc-api built from source, so if it's that, it can drop sun-j2me-bin. If it's midp-api, I can add it too.
Ok, As of 4.1 and now 4.2 you can build without j2me. I (think) can add a check to 4.2 to prevent building of the j2me component for bsd. Is there a bsd compatible j2me package we can use instead?
The only class that is imported from sun-j2me-bin when building proguard-wtk.jar is com.sun.kvem.environment.Obfuscator. I could not google out any alternative implementation.
By now sun-j2me-bin is an optional dependency. Current proguard already has a ~x86-fbsd keyword.
(In reply to Ralph Sennhauser from comment #8) > By now sun-j2me-bin is an optional dependency. Current proguard already has > a ~x86-fbsd keyword. closing then