ebuilds of openbabel in portage do not install bindings in directory 'scripts'. Only java is marked as experimental, the others should work (and are referenced on openbabel site). Reproducible: Always
Thanks for the report. I'm aware of several problems with the openbabel build. I'm working on using a few USE flags to make this package behave :)
Created attachment 175316 [details, diff] improved dependencies; install python bindings The attached patch to the openbabel-2.2.0 ebuild (although surely far from being perfect) introduces several use-flags to customize the behaviour of this package. If the python use flag is enabled it also creates and installs the python bindings.
Created attachment 181396 [details] New ebuld with python use flag and default zlib flag I made few changes to the previous patch. Still this requires quite some work, but it is now possible to install python bindings (as it was with that patch). The bug #206574 might not be considered closed for ebuild in Portage, but with these changes it might be as well as closed. Removed pic use flag, because, it is not the right way to deal with -fPIC (<a href="http://www.gentoo.org/proj/en/devrel/handbook/hb-policy-ebuild.xml">see Gentoo policy</a>). Removed also static use flag, because, if I understand right, it only produced static libraries along with dynamic ones, so I left that enabled. The right flag for static use might be --disable-dynamic-modules, but it has to be verified that it actually produces statically linked executables. wxWidgets GUI is disabled by default already. Python bindings has to be compiled after openbabel is installed so it links to the right library. Right now it is done in src_install(), but it might be better to split it in separate packages (pybel, openbabel-perl, openbabel-ruby). Even more so it is for Perl and Ruby bindings, because, they rely on finding openbabel in LD_LIBRARY_PATH (were it is only after merge). I'll soon put the separate ebuilds for swig bindings here. Any comments on this would be much appreciated.
Created attachment 181438 [details] Initial openbabel-perl ebuild
Created attachment 181439 [details, diff] Perl Makefile.PL patch for openbabel-perl Makes sure that openbabel-perl is linked against openbabel. With this example.pl script is working.
Created attachment 181451 [details] Initial openbabel-ruby ebuild
Created attachment 181548 [details] Updated ebuild; SWIG bindings now are in separate packages
Created attachment 181550 [details] Doxyfile patch for openbabel-2.2.0
Created attachment 181553 [details] Python bindings for OpenBabel
Created attachment 181555 [details] Updated openbabel-perl ebuild
Created attachment 181556 [details] Updated openbabel-ruby ebuild Right now rebuilding of SWIG bindings is not enforced even with swig use enabled. Maybe it should be changed.
Created attachment 181558 [details, diff] Diff against current ebuild in portage
Added to science overlay
OK, life has been hectic and this slipped my mind. I honestly do not see the need to make multiple split packages for each binding. I know this seems to get done more and more now, but openbabel needs the same version of the library and the bindings installed. I have added sci-chemistry/openbabel-2.2.2-r1 to the tree. This has the python and swig use flags and is inspired by your patch. As far as I can see openbabel is linking to zlib whether it is enabled or not here. I will look into that if I get chance. So I did not add the use flag. I think that the openbabel ebuild should be expanded to include use flags for each of the language bindings. The bindings will only ever be updated with a new release of OpenBabel. If there is a compelling reason to split everything then please tell me. Otherwise, I will add use flags for the other language bindings when I get chance. Please let me know about any issues with the new ebuild.
Initially I made split ebuilds for bindings, because that was more straightforward for me. But I still advocate separate ebuilds, because it avoids rebuilding openbabel each time a binding is added/removed and it keeps ebuilds cleaner, too.
Could you please bump the ebuild in the overlay? I will check whether they could be included in the tree then.
Thanks for all the preparation work, its in the tree now.