I'm considering replacing the common-lisp-controller system in Portage
with and opt-in, asdf-binary-locations approach.
The main purpose of the c-l-c is to provide a way to compile the
source in /usr/share/common-lisp to a user read/writable location
(currently the c-l-c uses /var/cache/common-lisp-controller/...).
The c-l-c also provides a way to register and unregister Common Lisp
implementations provided that each implementation comes with the c-l-c
support (usually a install-clc.lisp and a driver script for
installation under /usr/share/common-lisp/bin). It also provide a way
to register user sources (by creating a symlink from the user's source
into ~/.clc).
The perceived[1] problems with the c-l-c are that it is too intrusive,
makes debugging hard for upstream authors when problems arise and it
is not well understood.
I'm proposing that we replace the c-l-c with a light weight system
based on asdf-binary-locations[2]. Each Common Lisp implementation we
support would be essentially a vanilla build of upstream -- nothing
saved into the Lisp image.
Common Lisp library ebuilds (those that start with "cl-" in the
dev-lisp category) would record the pathname where the Common Lisp
system definition is installed. eg.
/usr/share/common-lisp/source/cl-ppcre/
The list of pathnames would be saved in, say, /etc/asdf-source.list
(one per line perhaps) and be CONFIG_PROTECT'd as usual.
If the user intends to make use of the dev-lisp/cl-* ebuilds in
Portage, they would include a short stub of Gentoo-provided code in
thier implementation initialization file (eg. ~/.sbclrc, ~/.clisprc
etc.) to add each of those recorded paths to ASDF:*CENTRAL-REGISTRY*.
They would then configure and load asdf-binary-locations from their
initialization file in order to direct compilation output to their
user read/writable location (eg. ~/.fasls/).
Natually there will be a Gentoo Guide XML document for these details.
I think this scheme is more in line with our Emacs approach in
portage. This has been a popular system for those who want a
distro-maintained Emacs build but want to use their own configuration.
We install Emacs libraries to /usr/share/emacs/site-lisp and maintain
a /usr/share/site-lisp/site-gentoo.el with the Gentoo provided
initialization code. This way users are not forced to use the Gentoo
configuration -- in fact, you have to opt-in in Emacs' case by loading
/usr/share/emacs/site-lisp/site-gentoo.el from your ~/.emacs.
Footnotes:
[1] from comp.lang.lisp and freenode.net #lisp
[2] http://common-lisp.net/project/cl-containers/asdf-binary-locations/
--
Matthew Kennedy
Gentoo Linux Developer (Public Key 0x401903E0)
--
[email protected] mailing list