Re: ASDF Builder (Common Lisp) & "package-inferred-system" Packages

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

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> Hi!
>
> It's been a while, and now that I'm on the verge of releasing Next 1.3
> and a dependency is a package-inferred-system, I thought it would be the
> perfect time to dig out this issue! :)
>
> So I'm trying to package cl-dbus (https://github.com/death/dbus).
> You'll find the recipes here:
> https://gitlab.com/atlas-engineer/next-guix-channel
>
> I can package it in several ways, but the result does not work for the
> reasons mentioned in this topic.

Hello again, Pierre! I apologize for being silent on this for so long.
I'm juggling a few things at the moment and will return to Guix commits
as soon as I can.

Regarding package inferred systems: I would really like to be able to
package them into a single Guix package as we do any other library, but
I think that will require some hacking on the ASDF build system. If I'm
remembering correctly, we would have to:

- Stop rolling all code into system-fasls
- Output each file's equivalent fasl to a common directory for the
  system
- Set a search path in the profile to recursively search the SBCL fasl
  output tree for systems.

In the interim, an idea I had was to borrow the "base package" concept I
came across when packaging other, non package-inferred, systems. I
haven't tried it yet, but I think it should work, even if it sounds
tedious to me.

Sticking with the dbus example, it looks like we have the following
situation:

- dbus
  - dbus/all
    - dbus/utils
    - dbus/protocols
    - ...

I think what we could do is define a `dbus-base` package which is
hidden, and then start defining "sub-packages" which simply inherit from
the base package, i.e.:

- dbus-base
  - dbus-utils (inherit from dbus-base)
  - dbus-protocols (inherit from dbus-base)
  - ...
  - dbus-all (inherit from dbus-base; require dbus-utils,
    dbus-protocols, etc.)

In essence we would be manually defining the dependency tree that ASDF
is inferring. We could probably lean on Common Lisp and ASDF itself to
generate these packages within a hypothetical importer.

But as I said, this seems quite tedious. We really should make our
Common Lisp packaging smarter.

-- 
Katherine