[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Dealing with language bindings for libraries.
From: |
Ricardo Wurmus |
Subject: |
Re: Dealing with language bindings for libraries. |
Date: |
Wed, 09 May 2018 22:08:51 +0200 |
User-agent: |
mu4e 1.0; emacs 25.3.1 |
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