Fis Trivial <ybbs.da...@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