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

[Andy Patterson]

Hey Katherine,

On Sat, 12 Jan 2019 14:24:38 -0600
Katherine Cox-Buday <address@hidden> wrote:

> I've done some more digging, and I have a better idea of why this is
> failing.
> 
> Running `(asdf:operate 'asdf:compile-bundle-op :foo)` on a
> `package-inferred-system` produces several `.fasl` files -- one for
> each sub-package instead of the usual `foo--system.fasl` file. The
> `cleanup-files` phase then deletes[1] any `.fasl` files which do not
> have a `--system.fasl` suffix.
> 

This phase has always been a bit of a hack.  There are already some
other packages where asdf doesn't produce an output file which matches
the expected name, so we had to change that.  I'd be in favour of
removing the phase wholesale until we can create one which works
better.  Ultimately we should be querying asdf for the output files
that it produced, and allowing the phase to be switched off with an
argument.

> I tried working around this by manually concatenating all the `.fasl`
> files together using `uiop:combine-fasls` which I believe works. I
> also had to add a new build phase to take place after the
> `create-asd-file` phase to do a string replace to change dependencies
> back to the `foo/bar` style instead of `foo-bar`.
> 

We've done something similar (the opposite) with the slynk package so
it's not unheard of.  If there's a better way to handle it though, we
should give it a go.

> I still believe the build system should handle
> `package-inferred-system` style CL packages properly so that
> maintainers don't have to do this kind of tweaking for every package
> (the number of which I believe will steadily increase).
> 

Definitely agree here.  We currently don't have overly many packages
relying on the build system so now would be a great time to fix it as
much as possible.

> I'm trying to confirm that this whole things works, but I believe I
> may be hitting another bug with CL being able to find dependencies.
> It seems as though even if the dependenices are listed in the
> generated `.asd` file, and my Guix SBCL can find that `.asd` and
> attempt to load its system, SBCL cannot find the dependencies.
> 
> I'm trying to determine why this might be, but it's currently blocking
> me from proposing a patch which adds 44 CL packages.
> 

Hmm, I'd need to see more information here to be able to offer anything
useful.  I think I've ran into similar problems in the past but I don't
remember what the solutions were.

> My current theory is that we perform a `setf` on the
> `*source-registry-parameter*` variable, but the ASDF manual
> specifically, and strongly, says[2] that this is meant to be a
> read-only variable. Maybe this is not working as intended?
> 

It's possible - this was the best way that I found at the time to
associate a system with a file directly.  AFAIK there's no way to ask
asdf to load a system from a file directly.  Any suggestions here are
welcome.

> [...]

Thanks,

--
Andy