Re: Dealing with language bindings for libraries.

[Ricardo Wurmus <rekado@elephly.net>]

Fis Trivial <ybbs.daans@hotmail.com> 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