[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 01/13] build-system: Add asdf-build-system.
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH v2 01/13] build-system: Add asdf-build-system. |
Date: |
Sat, 08 Oct 2016 14:39:19 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi Andy,
Andy Patterson <address@hidden> skribis:
> On Fri, 07 Oct 2016 14:44:38 +0200
> address@hidden (Ludovic Courtès) wrote:
[...]
>> Andy Patterson <address@hidden> 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’.
- [PATCH v2 10/13] gnu: Add cl-clx., (continued)
Re: [PATCH v2 00/13]: Add asdf-build-system., Ludovic Courtès, 2016/10/06
Re: [PATCH v2 00/13]: Add asdf-build-system., 宋文武, 2016/10/08