Pierre Neidhardt <m...@ambrevar.xyz> writes: > Konrad Hinsen <konrad.hin...@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
