General----------------------------------------------------------------------- An ebuild for Max-Gerd Retzlaff's enhanced version of Dan Barlow's presentation software called acclaim. Includeded are an ebuild for its current version (0.24) and two patches (acclaim.lisp and acclaim.asd). Some comments------------------------------------------------------------------ When makeing the ebuild I've noticed something weird about loading multiple asd files with portage's "common-lisp-install" function. Acclaim requires that the :ppm package be loaded before :acclaim. "Common-lisp-install" seems to load asd files alphabetically, so it doesn't work well in this instance. I worked around that by patching both definitions into acclaim.asd. This also gave me a good chance to change the :clx requirement in the asd file to allow for cmucl's :cmucl-clx. I havn't fully tested it on cmucl, so I can't guarantee anything. This as a whole this is a sloppy fix and I was wondering if you knew of a better way of handling the asd loading issue? Another issue with acclaim is that it likes to have a pathname supplied for a slides homedirectory (acclaim::*slides-pathname*). This is ofcourse checked as soon as acclaim is loaded, so maybe a standard user path could be setup. Otherwise, the patch I made to acclaim.lisp will set this value to nil. Thanks --Elliott
Created attachment 42542 [details] ebuild for acclaim-0.25
Created attachment 42543 [details, diff] patch for acclaim.lisp changes the value of acclaim::*slides-pathname* to nil instead of MGR's path
Created attachment 42544 [details, diff] a patch to acclaim.asd This patch adds the asd definiton of :ppm to the start of acclaim.asd. I couldn't figure out how to load ppm.asd before acclaim.asd using the "common-lisp-install" command. This is 100% jury-rigged. I added in a few lines to the :clx requirement to allow cmucl to compile it. I've gotten it to display with cmucl, but I'm not sure if every detail functions.
Heh I just realized that this is version 0.25 not 0.24.
Created attachment 42654 [details, diff] Revision of acclaim.patch I adjusted the acclaim.lisp file to allow for an "home:.acclaim" rc file.
Hi ejohnson, I have been playing around with this port getting it to work with clisp, sbcl and cmucl and also the portable CLX library (dev-lisp/cl-clx). Some notes: Do you mind if I change the ebuild header to the Gentoo boiler plate (see: /usr/portage/skel.ebuild)? This includes copyright assignment to Gentoo Foundation etc. The ChangeLog will include the port's attribution.
Sure, go for it :) I'm glad to see you've ported acclaim so widely. Also, I'm still wondering about the common-lisp-controller install and how that works with multiple .asd files?
When there's more than one system definition file in a port, they are usually distributed as "sub-components" (see: dev-lisp/cl-sql for an example). In the case of Acclaim, PPM is not a component of ACCLAIM, so I could install it at the top of the controller's root (/usr/share/common-lisp/source/ppm/ppm.asd and symlink /usr/share/common-lisp/systems/ppm.asd), but since it is a system containing only one file (image-reader.lisp IIRC), I am tempted to concatenate the files ppm.asd and acclaim.asd and use that. Another option is to make PPM a component of ACCLAIM (dev-lisp/cl-sql style). I guess yet another option is to forget having a PPM system entirely and just merge image-reader.lisp with Acclaim's system.
I did some work porting Portable CLX back to CMUCL, and now Acclaim runs on implementations which are supported by CLX. I want to do more testing however. So far this CLX modification allows McCLIM from 20041227 (soon to be committed to Portage) to work with Portable CLX on CMUCL as well as SBCL. I am tempted to not include the CMUCL CLX implementation in the ASDF-installable repository in /usr/share/common-lisp/source when its installed with dev-lisp/cmucl-sources and instead have anything which depends on CLX to use Portable CLX (dev-lisp/cl-clx). Perhaps I can include a renamed version of CMUCL CLX in portage (dev-lisp/cl-clx-cmucl) for those who don't want the portable one. I think I might displease our Lisp users if I were to drop CMUCL CLX for Portable CLX like that. What do you think? It would simplify dependencies for ports like dev-lisp/cl-mcclim. eg. Current dev-lisp/cl-mcclim depends on both dev-lisp/cl-clx (for SBCL, CLISP) and dev-lisp/cmucl-sources (CLX with CMUCL) regardless of whether the use has CMUCL or SBCL/CLISP installed. Same would apply to any other CLX-using ports in the tree. In any case, I would do a detailed comparison of the Portable CLX and CMUCL CLX source base before any such changes.
Committed to CVS
.
