guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)


From: Programmer
Subject: Re: Lisp libraries: Other variants? (CCL, CLisp, etc.)
Date: Fri, 09 Nov 2018 15:17:53 -0500

>Sure: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/lisp-utils.scm
I've only taken a look at lisp-utils.scm so far.  I can see it explicitly 
supports sbcl and ecl.
It's possible to get most or all of this in purely portable Common Lisp, which 
would make adding
more implementations require no effort.

>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).

>I could be missing something.  Can you see a way around this?
I do see value in offering compiled forms of standalone Common Lisp programs, 
such as StumpWM, but
don't see the point in doing this with Common Lisp libraries.

The common way to do this in Common Lisp is to distribute the source and simply 
compile it as
needed.  It can be advantageous to have this choice easily.

The basic idea is simply that the system package manager installs libraries 
wherever it will and
places a file that will load this library and its own dependencies properly in 
the user's home
directory.  It would be simple to have it check for and load compiled versions 
if present or compile
them if not after loading for faster reloading.

So, this would enable you landing into a new system to, say, reuse your Common 
Lisp initialization
files that reference the directory and seamlessly pick up from where you left 
off, once the system
package manager installs things.

Does this idea make sense?

>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.
I thought Guix would be a good first place to propose this idea.  If it would 
be more appropriate, I
now have time to build a first approximation of this idea, although I lack the 
Guix knowledge for a
robust implementation.  I did provide a simple example of this in my initial 
message, which shows
the file a library would have that loads another library that has no 
dependencies.

>Fare (one of the maintainers) has talked about it a few times:
>https://fare.livejournal.com/190738.html and other articles.
I'll make certain to read this.  I've read some of his articles before.

>But who places those files?  Guix cannot.
>Did you mean the user guix-profile instead?
I'm not certain by what you mean.  I did ask around earlier and learned it's 
not uncommon for Guix
to place files in the user's home directory when needed.

I'm not particularly familiar with Guix terminology yet.

>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.
>The way we do it now is probably optimal.  See cl-sqlite for instance.
I'll need to take a look at those later.

>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).
You need not worry about discouraging me.  I'd be delighted to see ASDF and 
Quicklisp replaced with
more intelligent, simpler, and more secure solutions for this simple problem.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]