| 1 |
I'm considering replacing the common-lisp-controller system in Portage |
| 2 |
with and opt-in, asdf-binary-locations approach. |
| 3 |
|
| 4 |
The main purpose of the c-l-c is to provide a way to compile the |
| 5 |
source in /usr/share/common-lisp to a user read/writable location |
| 6 |
(currently the c-l-c uses /var/cache/common-lisp-controller/...). |
| 7 |
|
| 8 |
The c-l-c also provides a way to register and unregister Common Lisp |
| 9 |
implementations provided that each implementation comes with the c-l-c |
| 10 |
support (usually a install-clc.lisp and a driver script for |
| 11 |
installation under /usr/share/common-lisp/bin). It also provide a way |
| 12 |
to register user sources (by creating a symlink from the user's source |
| 13 |
into ~/.clc). |
| 14 |
|
| 15 |
The perceived[1] problems with the c-l-c are that it is too intrusive, |
| 16 |
makes debugging hard for upstream authors when problems arise and it |
| 17 |
is not well understood. |
| 18 |
|
| 19 |
|
| 20 |
I'm proposing that we replace the c-l-c with a light weight system |
| 21 |
based on asdf-binary-locations[2]. Each Common Lisp implementation we |
| 22 |
support would be essentially a vanilla build of upstream -- nothing |
| 23 |
saved into the Lisp image. |
| 24 |
|
| 25 |
Common Lisp library ebuilds (those that start with "cl-" in the |
| 26 |
dev-lisp category) would record the pathname where the Common Lisp |
| 27 |
system definition is installed. eg. |
| 28 |
|
| 29 |
/usr/share/common-lisp/source/cl-ppcre/ |
| 30 |
|
| 31 |
The list of pathnames would be saved in, say, /etc/asdf-source.list |
| 32 |
(one per line perhaps) and be CONFIG_PROTECT'd as usual. |
| 33 |
|
| 34 |
If the user intends to make use of the dev-lisp/cl-* ebuilds in |
| 35 |
Portage, they would include a short stub of Gentoo-provided code in |
| 36 |
thier implementation initialization file (eg. ~/.sbclrc, ~/.clisprc |
| 37 |
etc.) to add each of those recorded paths to ASDF:*CENTRAL-REGISTRY*. |
| 38 |
|
| 39 |
They would then configure and load asdf-binary-locations from their |
| 40 |
initialization file in order to direct compilation output to their |
| 41 |
user read/writable location (eg. ~/.fasls/). |
| 42 |
|
| 43 |
Natually there will be a Gentoo Guide XML document for these details. |
| 44 |
|
| 45 |
|
| 46 |
I think this scheme is more in line with our Emacs approach in |
| 47 |
portage. This has been a popular system for those who want a |
| 48 |
distro-maintained Emacs build but want to use their own configuration. |
| 49 |
We install Emacs libraries to /usr/share/emacs/site-lisp and maintain |
| 50 |
a /usr/share/site-lisp/site-gentoo.el with the Gentoo provided |
| 51 |
initialization code. This way users are not forced to use the Gentoo |
| 52 |
configuration -- in fact, you have to opt-in in Emacs' case by loading |
| 53 |
/usr/share/emacs/site-lisp/site-gentoo.el from your ~/.emacs. |
| 54 |
|
| 55 |
|
| 56 |
Footnotes: |
| 57 |
[1] from comp.lang.lisp and freenode.net #lisp |
| 58 |
|
| 59 |
[2] http://common-lisp.net/project/cl-containers/asdf-binary-locations/ |
| 60 |
|
| 61 |
-- |
| 62 |
Matthew Kennedy |
| 63 |
Gentoo Linux Developer (Public Key 0x401903E0) |
| 64 |
-- |
| 65 |
gentoo-dev@g.o mailing list |
Archives