In the spirit of gcc-config, gtk-config and others antlr also provides antlr-config. However it is not installed by default for some reason. To be precise I needed it to compile formconv (not yet in portage) form http://formconv.sf.net/ I'd prefer having the doc useflag and not a ton of examples by default. Will attach patch to the ebuild. Reproducible: Always Steps to Reproduce: 1. emerge =antlr-2.7.4 Actual Results: which antlr-config => no such file Expected Results: which antlr-config => /usr/bin/antlr-config
Created attachment 50440 [details, diff] antlr-2.7.4.ebuild.diff * Add doc use flag, so some documentation may be installed optionally * Add /usr/bin/antlr-config to be installed
thanks for your report, commited.
Created attachment 50449 [details, diff] antlr-2.7.4.ebuild.diff [v1.1] Thanks for the quick response! While still on this bug... The bigger problem actually is that the package does not install the main executable :-) I know it is a library mainly, but still... I got tricked by dev-util/pccts-1.33.33, a package that instals /usr/bin/antlr. This patch will not work if pccts is installed, but don't know how to mark it blocking... pccts installs some very old antlr-1.33 And something else borken: PACKAGE_VERSION = 2.7.3 For example in ./configure and ./scripts/Config.make This shoulod probably go upstream, but can be fixed in portage as well. And finally the scripts/run-antlr is broken, partly because of PACKAGE_VERSION = 2.7.3... A quick'n dirty fix is to change ANTLR_JAR line to something like this (after install): ANTLR_JAR=$(perl -ne 'print if (s/CLASSPATH=(.*)/$1/g);' /usr/share/antlr/package.env) Sorry, I am dead tired for more patches today...
Somehow, I didn't reopen the bug, doing it now.
pccts should probably stop installing antlr but it doesn't seem to have a maintainer :(
I've just been looking at this: 1. This shouldn't be in dev-java. It is a code generator for C++/Java/C#, that happens to be written in java. dev-utils is the right place, Surprise! that's where pccts is. 2. pccts is an old version of antlr that is probably still needed to generate C (not C++) code, even assuming that the later version is otherwise backward compatible. So slotting is needed. 3. The pccts version of antlr (the executable) should be renamed as 'antlr-pccts' or just 'pccts'. Breaking the old version (which is in maintenance mode) will only break a finite number of applications. 4. Since you can use either pccts or antlr-2.x.x to generate parsers implemented in C++ (probably slightly different), 2 new USE flags are needed for dependents of anltr. Say, 'antlr1', 'antlr2'. Save 'antlr3' for the next version...;) 5. Fix antlr-2.7.5 ebuild so that the antlr script gets copied to /usr/bin 6. I'm happy to start fixing this, provided someone can sanity-check it.
Thanks for looking into it, your points seem valid I or someone else will defenitly santy-check it and add it to tree if you provide fixes not so sure if we need the use flags, will things that use(d) antlr1 work with antlr2 ?(if so asuming antlr2 is better, why do we need pccts/antlr1 at all) or should we always just depend on the specific version (like =antlr-1*)
Which is the status of Dave's fixing job? In portage the only package requiring dev-util/pccts as a dependency is cdrdao. I think both packages (pccts and antlr2) are necessary because they don't provide the same tools. For the same reason I think that slotting isn't the right solution.
I have updated the antlr ebuild for the version 2.7.5. The changes are the followings: * now the ebuild inherits also mono.eclass (see bug #87853) * I have added new use flags: debug java mono nocxx python * the jar file is now installed in /usr/lib * the antlr script is installed as /usr/bin/antlr2 * the examples are installed in a selective way I have installed the script as /usr/bin/antlr2: in this way dev-util/pccts can be installed at the same time. I have patched the pccts ebuild to rename its binary to /usr/bin/antlr1 and I have created an eselect module for antlr (looking at kernel.eselect). Now it's necessary to build an app-admin/eselect-antlr package adding it as dependency to antlr and pccts packages. I haven't tested mono use flags because I don't use mono :-) Please test it! It's better to move antlr from dev-java/antlr to dev-util/antlr Someone has to do sanity-check :-)
Created attachment 69540 [details] antlr-2.7.5.ebuild
Created attachment 69541 [details] antlr.eselect
Created attachment 69542 [details, diff] pccts-1.33.33.ebuild.patch
Created attachment 69543 [details, diff] genmk.patch The patch for pccts
Some feedback after a quick look at the ebuild: What is wrong with the standard location of jar files? # install the parser generator java-pkg_jarinto /usr/lib java-pkg_newjar antlr-${PV}.jar antlr.jar Now the way that java use flag is used is probably not something that users think it will do. It now controls the installation of examples for java. # in the following points einstall is required The support for the three different things could be done in a for loop or a helper function because the code seems to be the similar for every one of them. But I don't think this is strictly required.
Created attachment 69547 [details] antlr-2.7.5.ebuild The 'java' use flag is also used with econf so it enables java support for the package. I had chosen to install antlr.jar in /usr/lib to not patch /usr/bin/antlr2. Changes: * antlr.jar is now installed in the default dir (/usr/share/antlr/lib/) * removed the /usr/lib/antlr.py because it's already located in /usr/share/antlr * also csharp module goes only to /usr/share/antlr * installation is now cleaned with a helper function In this way all support libraries/modules go to /usr/share/antlr/ (only libantlr.a goes in /usr/lib).
Fixed in portage. Please sync and test in about 2 hours. Added a blocker on pccts so no need to change the binary name.
I have just tried the new ebuild. Here there are some notes, see also comment #6 I think that blocking pccts is a wrong choice because antlr and pccts packages don't provide the same functionality (for example antlr doesn't generate c code). In my opition it's better to use eselect and two executables (like for slotting). The ebuild is wrong. The java package antlr.jar is always needed, not only when the java use flag is enabled. Antlr is a parser generator written in java but the category of the package should be something different from dev-java.
Reopening. compnerd: Why the block when they don't collide with at the moment with each other as antlr does not install an antlr? I also agree that a better solution is needed than blocking because many people, including myself, need both pccts and antlr as dependencies.
I thought I had the latest version installed. Well it seems that it does now install the binary. Sorry about the noise.
(In reply to comment #19) > I thought I had the latest version installed. Well it seems that it does now > install the binary. Sorry about the noise. Yes, but with USE="-java" it doesn't install the .jar file needed by the binary itself
The jar install issue has been resolved. As for the pccts/antlr block, that is because antlr is suppose to supersede pccts.
(In reply to comment #21) > As for the pccts/antlr block, that is > because antlr is suppose to supersede pccts. as others said it before, antlr lacks one feature of pccts: C output. so it doesn't exactly replace pccts, look at http://www.antlr.org/doc/index.html and notice the comment: "You can use PCCTS 1.xx to generate C-based parser". so i agree with comment #6 on this, let the pccts version live on its own.
Okay, removed the block on pccts, and made it dependent on the script useflag which installs a userland script to run antlr. Regular drill applies.
Which is the problem in using eselect to switch between old and new antlr?
(In reply to comment #24) > Which is the problem in using eselect to switch between old and new antlr? > They are not replacements for each other.
(In reply to comment #25) > They are not replacements for each other. > Ok, now I have understood the problem. But there is an easy workaround. For example, during cdrdao installation with +pccts, the ebuild could * get antlr simlink status (eselect show) * set the required simlink to antlr1 (eselect set antlr1) * installation * restore the original simlink (eselect set $old_antlr)
