Re: [PATCH v2 01/13] build-system: Add asdf-build-system.

[Ludovic Courtès]

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’.