From: Katherine Cox-Buday <cox.katherine.e@gmail.com>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: guix-devel@gnu.org
Subject: Re: ASDF Builder (Common Lisp) & "package-inferred-system" Packages
Date: Sat, 03 Aug 2019 09:14:17 -0500 [thread overview]
Message-ID: <87r26272va.fsf@gmail.com> (raw)
In-Reply-To: <87sgqiu11w.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Sat, 03 Aug 2019 10:04:59 +0200")
Pierre Neidhardt <mail@ambrevar.xyz> writes:
> Hi Katherine!
>
> One of the issue that we have with the current build system is that it
> does not find the dependencies properly for the inferred packages.
>
> Robert from the ASDF team suggested a solution:
>
> https://gitlab.common-lisp.net/asdf/asdf/issues/10
>
> I think if we use his more general function, we can properly populate
> the *source-registry*. So that would be a solution to the first of our
> problems, that of the missing inputs.
Perfect!
> The main other issue is the one you mention: we need to compile the
> .fasl files right.
>
>> - 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.
>
> This sounds reasonable. Also you mentioned above that concatenating the
> generated fasl files into a single one manually worked for you. If it
> works, then why not!
I never got this to work[1]. I think Ningle's systems are being bundled
into a single fasl, but for whatever reason, its subsystems cannot be
found despite that bundled fasl being on the path.
Last I looked at this, I remember being left with the distinct
impression that we would have to stop producing system fasls, and rather
than having one directory of system fasls, we'd have a tree of system
directories, each populated with all the fasls for a system e.g.:
- ~/.guix-profile/lib/sbcl/
- dbus/
- dbus-all.fasl
- dbus-utils.fasl
- ...
And then find a way to search ~/.guix-profile/lib/sbcl/ recursively. The
ASDF manual says[2] $XDG_CONFIG_DIRS/common-lisp/source-registry.conf
can hold configurations, as well as `CL_SOURCE_REGISTRY`. Maybe Guix
could set one of these in the profile to something like `(:tree
(:home ".guix-profile/lib/sbcl/"))`.
Or we could stick to the `*source-registry*` variable and use a smarter
Common Lisp function to populate it.
> I believe your above solution could work. Wanna give it a shot?
Currently I have 1 day a week to work on open source things, and I have
been busy with other projects. Those may be wrapping up "soon", and then
I could give it a go, but I don't think you want to wait for me :) I
also don't speak Guile very well, and these larger changes to the build
system would probably take me awhile. It would probably be faster and
help to educate me if I were a reviewer on patches you produce.
I also want to mention that I remember going around in circles on this a
bit, so take everything I say here with a grain of salt. I think
experimentation is needed to find the cleanest implementation!
> Andy, what do you think?
[1]- https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00204.html
[2] - https://www.common-lisp.net/project/asdf/asdf.html#Configurations
--
Katherine
next prev parent reply other threads:[~2019-08-03 14:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 0:25 ASDF Builder (Common Lisp) & "package-inferred-system" Packages Katherine Cox-Buday
2019-01-11 9:01 ` Pierre Neidhardt
2019-01-11 15:34 ` Katherine Cox-Buday
2019-01-12 20:24 ` Katherine Cox-Buday
2019-01-13 19:14 ` Andy Patterson
2019-01-14 0:20 ` Katherine Cox-Buday
2019-08-02 16:28 ` Pierre Neidhardt
2019-08-02 16:43 ` Pierre Neidhardt
2019-08-02 17:37 ` Pierre Neidhardt
2019-08-02 20:27 ` Katherine Cox-Buday
2019-08-03 8:04 ` Pierre Neidhardt
2019-08-03 8:44 ` Pierre Neidhardt
2019-08-03 14:14 ` Katherine Cox-Buday [this message]
2019-08-06 10:41 ` Pierre Neidhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r26272va.fsf@gmail.com \
--to=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--cc=mail@ambrevar.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.