[CM] question on audio distributions, CCRMA or Agnula, others?

[Fernando Lopez-Lezcano]

On Wed, 2005-03-02 at 04:35, Rick Taube wrote:
> >> Ugly hack only. Building the debs is actually rather trivial - it's 
> >> the
> >> dependency checking that is rather hard if you want it to be usefull.
> 
> there are no dependencies. since the last release of cm you can build 
> all the systems separately then load what you want at run time. for 
> example, depending on what im doing these days i start cm and then load 
> in either clm2 or clm3. if midishare is properly installed it is 
> automatically loaded.
> loading these systems at runtime is fast, flexible and lets you stay 
> current -- saving images doesnt make much sense anymore unless your 
> goal is to keep a snapshot "stable" (whatever that means with software 
> like this!)  all three -- clm, cmn and cm -- check at runtime to see if 
> their fasls are out of data, and if so, they get compiled so 
> installation and running is identical. 

That is true for a user that installs in his/her/its home directory (or
somewhere else where he has write access) and has complete control of
the software. 

It is not possible to do that on a packaged version of cm/clm/cmn (at
least the way I package it), the user of the software is typically not
the installer (root) and will not have write access to the packaged
binaries. 

Planet CCRMA has had Common Lisp based packages for cm/clm/cmn since
2001. The packaging approach I have used lately is to load the prebuilt
systems at runtime on top of a clean lisp image (this is for cm 2.4.x,
clm2/clm3 and cmn). Maybe this could be used as "inspiration" for other
packagers. The current package structure is like this (this is after
several iterations over the years on how to package the stuff):

clm -> source code only, common to all lisps
clm-cmucl -> requires "clm" and "cmucl", packages all cmucl binaries
clm-sbcl -> requires "clm" and "sbcl", packages all sbcl binaries
clm-xxx for other supported versions of lisp

same with clm2 prefix for a backwards compatibility package for clm2.
same naming and packaging scheme for cmn.

So, installing a working clm for a particular lisp in Planet CCRMA is
just "apt-get install clm-cmucl". I presume this could be converted into
an "emerge clm-cmucl" command :-) The binary packages include a simple
subsystem lisp stub that loads what's needed, and a one line bash script
installed in /usr/bin that starts that particular flavor, so just typing
/usr/bin/clm-cmucl starts the cmucl version of lisp and loads all of
clm. Same mechanism for cmn. 

Cm is sligthly different as it contains hooks to signal loading the
other packages (this is still 2.4.x, the latest official release):

cm -> source code only
cm-cmucl -> requires "cm" and "cmucl", packages all cmucl binaries
cm-xxx for other supported lisps
cm-clm-cmucl -> requires "clm", includes just one file that signals the
cm startup code to load clm before loading cm into the lisp image.
cm-clm-xxx for other supported versions of lisp
cm-cmn-xxx for cmn and supported versions of lisp

So, installing "apt-get install cm-clm-cmucl cm-cmn-cmucl" will install
the whole thing and after that typing "/usr/bin/cm-cmucl" will load
everything into a fresh copy of lisp (clm, then cmn, then cm). 

Or, installing "apt-get install cm-clm-cmucl cmn-cmucl" will install
everything but will only load clm and cm on startup when typing
/usr/bin/cm-cmucl, after that it would be possible to load cmn by saying
"(require 'cmn)".

Anyway, I'm sure there are better, more clean and lispy ways of doing
all this. Still, probably the packaging structure and dependencies are
fine. 

I also have packages for slime so that it is easy to run any of these
packages as subprocesses of emacs or xemacs. 

More details available on request (file structure within a package,
details and so on and so forth, many small details had to be hacked for
this to work). Or download the relevant source packages from:

 http://ccrma.stanford.edu/planetccrma/mirror/all/linux/SRPMS/

-- Fernando

> so for cm installation is:
> 	tar -zxf cm.tar.gz
> and running is:
> 	cm/bin/cm.sh
> 
> asdf installs can just load src/cm.lisp or if they need more control, 
> load src/make.lisp and call make-cm with the appropriate arguments.
>
> On Mar 1, 2005, at 10:21 PM, M. Edward (Ed) Borasky wrote:
> 
> > rm@fabula.de wrote:
> >
> >> I'd rather go for ASDF-installable versions of cm/clm/cmn. That's all 
> >> that's
> >> needed to cooperate with CLC.
> > I think that's the approach the Gentoo packager is taking, but without 
> > documentation, I have know way of knowing what he is doing or why. :) 
> > Since I've got the attention of CM/CLM/CMN users, what are the 
> > tradeoffs between having them individually packaged and packaged as a 
> > bundle as described in the documentation? I do plan to use both CM and 
> > CLM, but probably not CMN. So if I get them packaged separately, it 
> > will be a minor inconvenience, and if I get them packaged as a bundle, 
> > there might be a memory hit at run time I don't need.
> >
> >> Ugly hack only. Building the debs is actually rather trivial - it's 
> >> the
> >> dependency checking that is rather hard if you want it to be usefull.
> >>
> > Yeah ... especially when you have the option of Guile, Clisp, CMUCL or 
> > SBCL as you do with CM 2.5.0.
> >