Ricardo Wurmus writes: > Fis Trivial <[email protected]> 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--- > > 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). >
Yes, I know. It's an example I can come up with, in order to make some discussions. I would argue that an output is at least conceptually a package. I don't have many experiment with RPM, but I know that there are source packages and binary packages. To me, in guix, the scheme package definition combined with the upstream source is the RPM version of source package, and the built store output is the RPM version of binary package. As for the recursive problem, I get that. I haven't really implement anything yet, so it's just an example of thought. I have hard time reading scheme code, thanks to syntax rules, diving into a new project is like learning a new language by reading it's compiler's source code which is also written in this new language. I will take my time to get into it. Not important here. > That’s not how the package DSL works, and I don’t think it should work > like this. Why you think it shouldn't work like this? I hope some of core members (you people are better program designer than me) can discuss this, if it's a implementable and accepted feature, I will try harder to get into the source code and help. > > 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. > Actually, this topic has came up a few times now, optional dependencies. It could be done in Nix and RPM. I am not saying guix should do what others done. But it makes a lot of sense of having that in tool box. >> 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. Maybe not. But maybe we can discuss possible some improvement for the future. :) Thanks.
