Re: Problems with McCLIM (Common Lisp)

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Konrad Hinsen <konrad.hinsen@fastmail.net> writes:
>
>> That sounds good, as does getting rid of ADSF bundles. I have more or 
>> less given up on numcl, for example, which fails to compile to a bundle 
>> in recent versions but seems to work find via fasls (at least it works 
>> fine with quicklisp).
>
> It seems that the Common Lisp community is mostly relying on Quicklisp
> and thus rarely, if ever, uses asdf:compile-bundle-op.
> The latter has been a source of oddities to me: several times a piece of
> code would behave differently between compile-bundle-op and compile-op.
> Upstream is almost always relying on compile-op and thus not aware of
> the compile-bundle-op issues.

It's been awhile since I packaged any new Common Lisp systems into Guix,
but I most often experienced this with the new package-inferred style of
systems (you can probably find my messages in the guix-devel archives).

To try and side-step the aforementioned issues with Guix's bundling
code, I tried using the compile-bundle-op operation and a few others,
and none of them worked with package-inferred systems. I believe I did
some research and found that there was some esoteric reason these
operations didn't work with package-inferred systems. I would be
delighted if they did.

We do need to overhaul how we package Common Lisp software in general.
Regardless of whether the functionality we're discussing works, I think
we have many more "standard" options for laying out packages and fasls
on disk. We might want to consider looking closely at what Quicklisp
does and see if we can't map that onto the store.

I'm glad people like Pierre are looking into this! I wish I had more
time to help at the moment, but: 2020.

-- 
Katherine