I noticed when installing sqlitebrowser, which is a c++ program, it pulled in antlr:0[cxx] and also a JDK at runtime. Removing USE=java from antlr (I didn't realize until today that it also was a c++ library) and the JDK is still required. There is a TODO in the antlr-2.7.7-r5 ebuild about this very issue. Is it possible that the virtual/jdk should be optional based on the presence of USE=java. Some of this seems to have changed in the 3.x and 4.x ebuilds, but it still hard RDEPENDs on virtual/jre, and adds a new dev-java/stringtemplate dep (which is also not optional). It seems wasteful to install a JDK/JRE on a machine for a C++ library that doesn't require it. I tried making the changes in my own overlay, and the inherit java-pkg-2 seems to fail if there is not a VM present no matter what. Is this a design limitation? I notice that inherit mono doesn't require a C# runtime if it is not used. I'll attach my attempt at an ebuild anyway in case it helps explain. Reproducible: Always
Created attachment 413970 [details] Attempt at changing the 2.7.7 ebuild, as noted, inherit java-pkg-2 causes it to fail
Chewi is your man for all things antlr.
I am completely reworking the whole ANTLR situation and this has proven to be a very large task! Nearly done now though. I am currently splitting the C++ part of dev-java/antlr-2.7.7 into a new package, dev-cpp/antlr-cpp. This will not depend on Java at all. sqlitebrowser will still need to depend on dev-java/antlr and hence Java in order to build the grammar but only at build time. Would this meet your needs? Unlike some other projects, sqlitebrowser does include the generated sources so it is not strictly necessary to run antlr but Gentoo generally builds things like this unless it is a huge inconvenience.
Excellent, that is ideal! I did not realize that sqlitebrowser used the java portion at all, that makes total sense. I agree, bundled libs are not Gentoo. Then you get into issues when _their_ generated sources don't run against _our_ libantlr.so ABI, etc. etc.. In fact if it is anything like google protobuf, it will check and fail at runtime if it detects version mismatches. Side-question, does that mean sqlitebrowser should be sub-slotted against antlr? Please let me know when/where/how I can help test.
The generated sources are exactly that, C++ sources, so it would be an API breakage and a build time failure. This would only arise if the Java version of antlr they've used majorly differs from the C++ version of we're building against. This won't happen for a couple of reasons. antlr is not really backwards compatible so they couldn't just switch to version 3 or 4 without totally rewriting the grammar and the other sources that depend on it. By the same token, dev-cpp/antlr-cpp will be slotted by major version, though I don't currently intend to add any newer versions because nothing requires it right now. antlr 2.7.7 is also 9 years old (!!) so we're really not going to see any new versions in that series that could introduce breakages. So why would we build the grammar? In case someone wants to modify it? Because it's Gentoo? I dunno. Not great reasons, I'll admit. :)
I guess the gold-plated solution to satisfy all types would be to offer a USE flag that offered the bundled version that comes with sqlitebrowser, but that has nothing to do with this issue :) It would also be more of a maintenance burden, and since I don't do the work, I'll let the people who do decide that.
I got the bump to sqlitebrowser-3.7.0-r1 with the associated antlr-cpp change. Works as advertised here, thanks James! I did get a hard blocker, which I found weird since sqlitebrowser was the only package that pulled in dev-java/antlr, but it was solved easily by first unmerging sqlitebrowser, then antlr, then re-emerging. Shall we close this?
antlr-cpp blocks antlr[cxx] because the files would clash and I had hoped that Portage would unmerge antlr for you but I guess it's not that smart. I'll close this when the old antlr is cleared, along with a raft of other bug reports.
All sorted now!
Thanks much for your hard work! I was thinking about this the other day, how long before I should ask for stabilization of sqlitebrowser (and thus antlr-cpp)?
It's already been over 30 days so you can request it now if you like.
