Hi ! Please find attached libantlr3c-3.1.4.ebuild The package's source's archive format is not recognized by unpack so that I had to write manual extraction commands. libantlr3c is the C runtime library for the ANTLR parser. Florent
Created attachment 206336 [details] libantlr3c-3.1.4.ebuild
The question is: - Do we want separate bindings or make it part of antlr package itself? Are they released/versioned separately or together? Is this package at all usable standalone without the java part? (not even depending on it) - If separate, what category? Surely not dev-java... dev-util?
Created attachment 206986 [details] dev-libs/antlr-c-3.1.4.ebuild Thank you very much @florent for your contribution. Enhancements done to the ebuild: - removed src_unpack() as it's useless; an explicit declaration of ${S} is sufficient to fix the build path; - DEPEND/RDEPEND was wrong and not portage compliant; - removed USE 'abiflags' as it's required only for old and broken gcc 2.x which are not in the portage tree; - renamed USE 'antlrdebug' into 'debugger' to be more consistence with the other ebuilds that show similar features; - some improvements to the doxygen generation; - replaced 'einstall' call with a proper 'make' invokation; - added USE 'static-libs' to correctly handle static *.a file and removal of useless .la files; Hope to be useful. Mauro Toffanin > Do we want separate bindings or make it part of antlr package itself? > Are they released/versioned separately or together? antlr-c is a separated package from dev-java/antlr:3, but they are released together (accordling to upstream doc). > Is this package at all usable standalone without the java part? > (not even depending on it) yes, it compiles/run fine without dev-java/antlr:3 > If separate, what category? Surely not dev-java... dev-util? the package provides only header files and libraries, so 'dev-libs' is more appropriate.
Created attachment 206987 [details, diff] antlr-c-3.1.4-doxygen.patch
my last concern: we need to slot the ebuild as dev-libs/antlr:3 and provide also dev-libs/antlr-c:2?
(In reply to comment #5) > my last concern: we need to slot the ebuild as dev-libs/antlr:3 and provide > also dev-libs/antlr-c:2? Slot yes, provide :2 no (I think antlr2 bundles other language bindings in itself)
*** Bug 329541 has been marked as a duplicate of this bug. ***
The package is not usable without the original antlr, I've needed it for the forked-daapd ebuild and although ist was installed from this ebuild, forked-daapd config system didn' find it, so I think it needs an RDEPEND on antlr
(In reply to comment #8) > The package is not usable without the original antlr, I've needed it for the > forked-daapd ebuild and although ist was installed from this ebuild, > forked-daapd config system didn' find it, so I think it needs an RDEPEND on > antlr > Not really. If you need to generate grammars at build time then you DEPEND on dev-java/antlr and needed runtime libraries but at runtime you only need the runtime library.
ah ok, I didn't know this. In this case the forked-daapd needs dependency on antlr.
Created attachment 245431 [details] dev-libs/antlr-c-3.2.ebuild New and updated ebuild.
(In reply to comment #11) > Created an attachment (id=245431) [details] > dev-libs/antlr-c-3.2.ebuild > In order to have 3.2 of this we first need antlr-3.2 so before we have that I think it's safest to commit the matching version.
This package is in gentoo-x86 as dev-libs/antlr-c now, so it might be time to close this bug.
(In reply to comment #13) > This package is in gentoo-x86 as dev-libs/antlr-c now, so it might be time > to close this bug. Indeed, thanks.
