On 09/05/2018 20:00, Julien Lepiller wrote:
We already have such a case: capstone and python-capstone. There is no redundancy since python-capstone knows how to load the shared library created in the capstone package. So we have two packages, with the same
My situation is a bit different. The package I am working on (OpenBabel, http://openbabel.org/wiki/Main_Page) has a monolithic build process based on CMake that builds the library plus bindings for all languages that it detects in its environment. There is no obvious way to build the language bindings to go with an already installed library.
It's almost trivial to package in Guix for any language combination you care about: just add the languages you need to the inputs. It's also straightforward to make each language binding a separate output of the package. But choosing this option makes building the package very expensive.
Konrad.
