Re: Dealing with language bindings for libraries.

[Ricardo Wurmus]

Fis Trivial <address@hidden> writes:

>> 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---

That’s not how the package DSL works, and I don’t think it should work
like this.  An output is not a package and it does not have its own
inputs.  Nor can a package be recursively defined (here foobar refers to
foobar itself).

You cannot have it both ways: include inputs conditionally *and* have
the thing be one and the same package.  You *can*, however, define a
procedure that generates closely related packages.  But then these are
separate packages and don’t share the same build environment.

> 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.

I don’t think there *can* be a universal solution.  I’ve seen both kinds
of packages in the past; the solution depends on the build system.

--
Ricardo