dev-java/gjdoc-0.7.9-r1 doesn't build against antl-3.1.3-r2 or any antlr newer than 2.x Reproducible: Always Steps to Reproduce:
Please attach some sort of log which gave us a clue what your error looks like.
(In reply to comment #1) > Please attach some sort of log which gave us a clue what your error looks like. > Er, well, the ebuild wants >=2.7.1[java], which will always fail since antlr-3.1.3-r2 doesn't *have* a java USE flag. The gjdoc autotools script doesn't look for antlr3.jar (why the name change, anyway?), doesn't seem to look in the correct installed directory, either, the fragment "--with-antlr-jar=$(java-pkg_getjar antlr antlr.jar)" in the ebuild doesn't return the correct path with or without the correct jar name, and after a lot of diffing and patching and trying to twist emerge's arm behind its back, it looks like gjdoc is calling methods that don't exist anymore (I'm assuming antlr.* will always fail now that the package is antlr3). That last is pretty much where I gave up yesterday. I could just put antlr > 2.x in packages.mask, but I'd like to think the correct thing to do is beat gjdoc (and any other packages in the tree) into using the newer antlr.
(In reply to comment #2) > (In reply to comment #1) > > Please attach some sort of log which gave us a clue what your error looks like. > > > > Er, well, the ebuild wants >=2.7.1[java], which will always fail since > antlr-3.1.3-r2 doesn't *have* a java USE flag. > Then your gjdoc ebuild is not from the main tree: betelgeuse@pena /usr/portage/dev-java/gjdoc $ grep antlr gjdoc-0.7.9-r1.ebuild >=dev-java/antlr-2.7.1:0[java]" local myc="--with-antlr-jar=$(java-pkg_getjar antlr antlr.jar) --disable-native" As you can see it requests slot :0 meaning 3* won't satisfy the atom.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Please attach some sort of log which gave us a clue what your error looks like. > > > > > > > Er, well, the ebuild wants >=2.7.1[java], which will always fail since > > antlr-3.1.3-r2 doesn't *have* a java USE flag. > > > > Then your gjdoc ebuild is not from the main tree: > betelgeuse@pena /usr/portage/dev-java/gjdoc $ grep antlr gjdoc-0.7.9-r1.ebuild > >=dev-java/antlr-2.7.1:0[java]" > local myc="--with-antlr-jar=$(java-pkg_getjar antlr antlr.jar) > --disable-native" > > As you can see it requests slot :0 meaning 3* won't satisfy the atom. > Partial quote. I'm using the main tree. Yes, I know 3* won't take care of it. I'd like someone to help me patch this to the point it'll work with >=antlr-3.1.3-r2. I spent an hour patching bits of the source and the ebuild, and now I've got it to the point it starts to compile using antlr3.jar, and t hen javac becomes very unhappy. Java isn't my strong suit, and I'm hoping someone can sort of take it from there. If anyone's interested-- well, I'll attach my patched files, regardless.
Created attachment 207318 [details] New ebuild with ugly hack for antlr3.jar path
Created attachment 207319 [details] files/antlr-ver-fix.patch - Touches quite a lot of files.
gjdoc should at least start to build with the attached files. After that, boom. If someone can take a look and help out? It would be nice to get rid of the old antlr build.
(In reply to comment #7) > gjdoc should at least start to build with the attached files. After that, > boom. If someone can take a look and help out? It would be nice to get rid of > the old antlr build. > If the whole point of this bug is that gjdoc should work with antlr-3* then you should work with upstream authors to port the code there. antlr:3 has a different ABI from antlr:0 so it's not just a matter of pointing to the new jar. When you have a working patch submitted the their version control system, you can reopen this bug and we can include it. On the Gentoo side the Gentoo Java team does not have the time currently to do such porting so closing as UPSTREAM as the ebuild itself doesn't have problems.
