From: Pierre Neidhardt <mail@ambrevar.xyz>
To: Programmer <programmer@verisimilitudes.net>
Cc: guix-devel@gnu.org
Subject: Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)
Date: Fri, 09 Nov 2018 12:02:36 +0100 [thread overview]
Message-ID: <87bm6y4ipf.fsf@ambrevar.xyz> (raw)
In-Reply-To: <bm6ykauv.fsf@server.domain.com>
[-- Attachment #1: Type: text/plain, Size: 4671 bytes --]
> : Have you looked at lisp-utils.scm? I think it incorporates some of your ideas
> : already. It could perhaps be generalized following your ideas so that it works
> : for all Lisps out of the box.
> I've not. I did a cursory search for this as well, but didn't find anything. Would you be so kind
> as to link me to it so I can give a good idea of whether it's similar or not?
Sure: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/lisp-utils.scm
More generally, you'd be better off checking out the whole repository. Then I
recommend you look at those files:
- guix/build-system/asdf.scm
- guix/build/lisp-utils.scm
- guix/build/asdf-build-system.scm
> I was aiming for something specifically suited to Common Lisp, since many Schemes have their own way
> of doing things, but if a general approach works best then that would be great.
I did not mean Scheme either. I don't know if something general enough could be
devised for Scheme as well. It's probably too ambitious ;)
> : Question: Are .fasl files compatible across Common Lisp implementations? If
> : not, then what's your suggestion?
> FASLs aren't standardized in form, so even the same implementation across different versions may be
> unable to use earlier or later FASLs.
>
> My suggestion, if this becomes an issue, is to have FASLs deposited in a fasl subdirectory of the
> Common Lisp directory with further subdirectories denoted by Lisp implementation name and it may be
> a good idea to think ahead and also use the particular version in the subdirectory name. This
> provides a simple, perfectly portable, and rather foolproof way to get the proper behavior for this.
But how do you build this for a single Guix package? If you want FASLs for,
say, SBCL and CCL, then you need to invoke both compilers when building the Guix
package. It would be much to heavy weight that every single Lisp package
depended on all Lisp compilers, plus it would result in disk consuming packages
that would benefit practically no one (no one uses all Lisp compilers at the
same time).
So we need different packages. Which is what we are doing at the moment.
Does that make sense?
I could be missing something. Can you see a way around this?
> : By "system", do you mean a _build system_ or something else?
> I meant something like ASDF, but more abstract and able to be compiled to representations including
> ASDF and Guix declarations and whatnot, with the reasoning that ASDF is rather grotesquely large and
> unwieldy, among other things.
If this is more general than Guix, does it still belong to the Guix project?
Shouldn't it belong to the Common Lisp community as a replacement for ASDF? I
know the Common Lisp community has been talking about replacing ASDF for a
while.
Fare (one of the maintainers) has talked about it a few times:
https://fare.livejournal.com/190738.html and other articles.
> : We want to install libraries in the store. Why do you suggest we put it in the
> : user's home?
> You misunderstand. The library would be in the store, but there would be a file placed in the
> user's home directory, because Common Lisp has a USER-HOMEDIR-PATHNAME function, that would handle
> loading dependencies and the actual library.
But who places those files? Guix cannot.
Did you mean the user guix-profile instead?
> : Sorry, I don't understand how your proposal would eliminate the POSIX-assumption
> : issue. Can you provide an example?
> Sure I can. It's been a while since I've tried this, but common Common Lisp tools to load code
> don't actually know anything about the structure of the system, so under POSIX they simply check the
> usual locations, instead. This blows up miserably under Guix, since it does things differently.
> With the idea of generating the code used to load things from a higher-level description, you can
> adapt it to the particular system, rather than simply checking many directories like it's a
> configure script or something.
My understanding is that CL-CFFI makes those assumptions. A few months back I
had brought up the issue upstream and they told me they were not eager to change
it.
https://mailman.common-lisp.net/pipermail/cffi-devel/2018-May/003048.html
The way we do it now is probably optimal. See cl-sqlite for instance.
I'm realizing my answers might come off as discouraging. I hope it's not, we
still need to work on the build system on the Guix side, while the Common Lisp
side would certainly benefit from improvements to ASDF (or its successor).
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2018-11-09 11:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 6:45 Lisp libraries: Other variants? (CCL, CLisp, etc.) Programmer
2018-11-09 11:02 ` Pierre Neidhardt [this message]
2018-11-09 20:17 ` Programmer
2018-11-10 10:02 ` Pierre Neidhardt
-- strict thread matches above, loose matches on Subject: below --
2018-11-05 1:35 Programmer
2018-11-05 21:03 ` Pierre Neidhardt
2018-10-20 10:10 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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bm6y4ipf.fsf@ambrevar.xyz \
--to=mail@ambrevar.xyz \
--cc=guix-devel@gnu.org \
--cc=programmer@verisimilitudes.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).