Currently, the ebuild supports python bindings only, and the ebuild is quite complex already. However, capstone supports multiple other additional languages, for example: java, ocaml, PowerShell, VB6, C#, Go, Ruby, NodeJS, C++ & Vala Some of these languages are written by community and must be downloaded separately. So I think it makes sense to split out all bindings into a separate ebuild. We have started to do it and you can try our ebuilds at Pentoo overlay. See also: https://github.com/pentoo/pentoo-overlay/issues/520
If the bindings are released as a part of the same source tarball I would prefer to keep it as a single package. Adding USE flags is not hard. That would ease bumping a package and keep library+bindings in sync as opposed to bump a bunch of packages. I'm not against adding more bindings support into existing ebuild.
I think the keyword is community bindings See https://github.com/aquynh/capstone/blob/master/bindings/README There are around 15 additional bindings, they are all hosted by different authors Please reconsider
(In reply to Anton Bolshakov from comment #2) > I think the keyword is community bindings > See https://github.com/aquynh/capstone/blob/master/bindings/README It does not help me to understand existing problem. > There are around 15 additional bindings, they are all hosted by different > authors > Please reconsider External packages maintained by their authors are standalone projects can go into their packages in gentoo. Why does it relate to canstone python (or other bundled) bindings that are part of capstone tarball?
well, ok. It may be make sense to write 15 separate ebuilds for each binding. Let me be this way.
