Hi Andy, Andy Patterson <ajpat...@uwaterloo.ca> skribis:
> On Fri, 07 Oct 2016 14:44:38 +0200 > l...@gnu.org (Ludovic Courtès) wrote: [...] >> Andy Patterson <ajpat...@uwaterloo.ca> skribis: >> >> > +(define* (package-with-build-system from-build-system >> > to-build-system >> > + from-prefix to-prefix >> > + #:key variant-property >> > + phases-transformer) >> > + "Return a precedure which takes a package PKG which uses >> > FROM-BUILD-SYSTEM, +and returns one using TO-BUILD-SYSTEM. If PKG >> > was prefixed by FROM-PREFIX, the +resulting package will be >> > prefixed by TO-PREFIX. Inputs of PKG are recursively +transformed >> > using the same rule. The result's #:phases argument will be >> > +modified by PHASES-TRANSFORMER, an S-expression which evaluates on >> > the build +side to a procedure of one argument. >> >> This code seems to be adapted from ‘package-with-python2’. It seems >> that ‘package-input-rewriting’ is too specific to be used here, but at >> any rate, we should keep an eye towards factorizing this and keep it >> as simple as possible to facilitate that. >> > > I'm not sure what the right abstraction is to encompass both. I’m thinking of (package-input-map proc), which would take care of the DAG traversal so we don’t have to rewrite that every time. >> Is #:variant-property necessary here? It was necessary in >> ‘package-with-python2’ due to python-2 and python-3 packages sometimes >> having a different set of dependencies. If it can be avoided here, >> it’s better. Otherwise that’s fine. >> > > It's necessary any time the variant package must differ from what the > transformer would ordinarily produce, so that a package which needs to > include the variant knows how to find it in the recursive step. In our > case, ecl packages may need different phases or outputs for binary > generation. > > Also, the dependencies could differ, for example stumpwm used to use > the built-in clx on ecl. OK, that makes a lot of sense; it’s similar to the Python situation. >> > +(define %install-prefix "/share/common-lisp") >> >> What about “lib/common-lisp” for architecture-dependent files >> (binaries)? What do other distros do? >> > > Binaries are placed in /lib/<lisp>/. /share/common-lisp is just used > for source or symlinked .asd files (as is the convention). The other > distributions I've seen which package Common Lisp libraries (Debian and > Gentoo) do not distribute binaries for systems, and what they do is > basically equivalent to the asdf-build-system/source. I > think /lib/<lisp>/ is a good place for binaries, since the > implementations place their extra included system binaries there, > roughly (/lib/sbcl/contrib; /lib/ecl-<version>). Alright. Maybe just add a comment next to ‘%install-prefix’ stating that this is the installation prefix for source, not for binaries (I had overlooked that), and maybe rename it to ‘%source-install-prefix’. > Cool. Fixes attached inline. No further comments from me. > Are the packages also OK? I'd like to start fixing any problems with > those as well. I’ll take a quick look and will leave the final word to 宋文武. Thanks for your patience! Ludo’.