Summary: | dev-java/libantlr3c-3.2.ebuild (New Package) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Florent <florent.teichteil> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | espenaf, flameeyes, java, luksan, saintdev |
Priority: | High | Keywords: | EBUILD |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 264196, 329315 | ||
Attachments: |
libantlr3c-3.1.4.ebuild
dev-libs/antlr-c-3.1.4.ebuild antlr-c-3.1.4-doxygen.patch dev-libs/antlr-c-3.2.ebuild |
Description
Florent
2009-10-07 16:22:28 UTC
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. |