Re: Dealing with language bindings for libraries.

[Fis Trivial]

Ricardo Wurmus writes:

> Fis Trivial <address@hidden> writes:
>
>> An ideal scenario would be the one that we can specify multiple outputs
>> for one packages, each output corresponds to one language binding, and
>> we can specify different dependencies and build system for each
>> output. Is there any chance we can do that in guix?
>
> Yes, we already use multiple outputs in some packages IIRC.

That's how I learn the term "output". :)

> We can also
> reuse parts of build systems without having to reimplement them
> manually.  We would simply reference them with something like this:
>
> --8<---------------cut here---------------start------------->8---
>   (add-after 'install 'strip-jar-timestamps
>     (assoc-ref ant:%standard-phases 'strip-jar-timestamps))
> --8<---------------cut here---------------end--------------->8---
>
Oh, I didn't thought about that before, thanks. But would something
similar to this be nicer?

--8<---------------cut here---------------start------------->8---
(define-public foobar
  (package
    (name "foobar")
    (source (origin ... ))
    (build-system cmake-build-system)
    (output "python"                    ; builds foobar-python
     `(package/inherit foobar
                       (name "foobar-python")
                       (source (getcwd))
                       (build-system python-build-system)
                       (inputs
                        `(,@(package-inputs foobar)
                          ("pytest" ,pytest)))
                       (arguments
                        `(#:phases
                          (modify-phases %standard-phases
                            (add-before 'configure 'cd
                              (lambda* _
                                (chdir "./python"))))))))
    (home-page "https://foobar.html";)
    (license ...)))
--8<---------------cut here---------------end--------------->8---

> Using separate independent outputs means that users who fetch
> substitutes can avoid fetching irrelevant substitutes.  This doesn’t
> help users who build everything from source as they’ll need to have the
> dependencies for all language bindings.

On the other hand, it will help people who don't everything from source,
I would say that's a large amount of people, including me.

>
> Dependent on the way this is implemented we can also have a common
> package and use that as an input to the separate language binding
> packages.  There would be no wasted cycles as the common parts would not
> need to be rebuilt.

I read the package definition of python-capstone as pointed out by
Julien Lepiller, thanks. It requires manipulating python build code to
achieve the effect. It's true that we can do that by inspecting build
code, but these language bindings are designed to be build in source
tree, I don't think the solution of python-capstone should be adopted as
an universal solution.