[CM] quicklisp clm

Juan Cristobal Cerrillo jccerrillo at me.com
Mon Dec 12 07:27:12 PST 2016


Per Ralf’s suggestions I’ve made some changes.
The asd file now includes a quicklisp directive and includes the original asdf:defsystem as well.

I’ve changed the way in that clm-directory was set, removing the concatenating to my invented clm directory and using ql:where-is-system, agin with a directive. This allows for correct c compiling without having to copy any files to the asdf compile directory.

If quicklisp is not detected, all should work as it did originally with asdf.

I am now able to load CLM with asdf:load-system, and quicklisp, in CCL and SBCL.

Best,

jc


> On Dec 11, 2016, at 1:41 PM, Ralf Mattes <rm at seid-online.de> wrote:
> 
> On Sun, Dec 11, 2016 at 06:16:21PM +0100, anders.vinjar at nmh.no wrote:
>>>>>>> "R" == Ralf Mattes <rm at seid-online.de> writes:
>>>> Good luck.
>> 
>>    R> Looking at the state of the code I think that's really needed.
>> 
>> I use the CL version of CLM from time to time, using sbcl and lw, and i
>> beleive some others also use CL/CLM at times.  What is it with the state
>> of the code you find problematic?
> 
> Just as a quick reply, not neccessarily in order of importance (and
> _not_ meant as a critique):
> 
> - a rather baroque way to build/install (that makes distribution via 
>   quicklisp rather unölikely). 
> - build-customization via *features* (again, not really working for
>   Quicklisp)
> - implementation specific loading of libraries (there's no real need to
>   maintain a list of *shared-object-extension* any more. Delegate all
>   of this to cffi). In general, a lot of the code could be factored out
>   to "general" libraries provided by Quicklisp (btw, the same is true 
>   for CM as well).
> - That extra strange mixture of autoconf and (c source) compilation
>   from lisp. I was trying to load CLM from the git repository but
>   compilation of the library failed (missing symbols). With a proper
>   makefile I would have been able to start to compile outside of lisp
>   and debug the build.
> 
> Now, non of this is impossible or even hard to fix, but it needs to be
> done and it's quite some work. I'm glad to see people work on that code,
> but, in my very humble, personal and probably grummpy opinion, it needs
> to be done by systematically cleaning up the code and not by adding
> another layer of fixups - that only makes the system even more brittle.
> Just one quick example: dir-setup.lisp uses
> quicklisp:*local-project-directories* and concatenates it with a string
> "/clm". Hmm, now we've lost the possibility to load CLM from asdf. And
> we can't install it with Quicklisp either (iff it's picked up by
> quicklisp at some point in the future). There's fine support to find the
> source code location in ASDF/UIOP. Why not use that?
> And don't assume quicklisp directories are writeable ... ;-)
> I hope I've made my poit clear. I did not intend to lessen anyones
> valuable work.
> 
> Cheers, Ralf Mattes
> 
> 
> 
> 
> 
> - 
>> -anders
>> 
>> _______________________________________________
>> Cmdist mailing list
>> Cmdist at ccrma.stanford.edu
>> https://cm-mail.stanford.edu/mailman/listinfo/cmdist
>> 
> _______________________________________________
> Cmdist mailing list
> Cmdist at ccrma.stanford.edu
> https://cm-mail.stanford.edu/mailman/listinfo/cmdist




More information about the Cmdist mailing list