[asdf-devel] MCL issue

Pascal Costanza pc at p-cos.net
Sun May 22 19:04:47 UTC 2011


On 21 May 2011, at 01:21, Faré wrote:

>> Logical pathnames work well as long as all your files follow the
>> naming restrictions. Which is not the case for all CL programs and
>> libraries, even less so when you're integrating with other languages
>> and their naming conventions, or (shudder) files that have version
>> numbers in them...
>> 
>> If they work well for you, more power to you.
>> But ASDF cannot possibly depend on them.
>> 
> Also, logical-pathnames require some magic setup to happen early in
> the system configuration. Details of such configuration is completely
> implementation-dependent, and it would be a bootstrapping catch-22 to
> require casual users to do this configuration before they could use
> ASDF. More work for less bang. Yet another reason why ASDF does not
> depend on logical-pathnames, and why I do not recommend that anyone
> should bother with them for anything remotely "portable". Of course,
> if you already paid the price, you're free to keep using them and live
> with their limitations.

The setup is not that hard. Here is what I have in my .sbclrc

(setf (logical-pathname-translations "costanza")
      `(("**;*.fasl.*" ,(format nil "/Users/costanza/.cache/common-lisp/~A ~A/**/*.fasl"
                               (lisp-implementation-type)
                               (lisp-implementation-version)))
        ("**;*.*.*" "/Users/costanza/**/*.*")))

This is all that is necessary, and it looks pretty much the same for all CL implementations. This can probably very easily be abstracted to make it even easier to set up.

I don't have anything against the support for Unix-style pathnames, but I don't think that ASDF is the right place to define them. Either they are useful for people who only care for Unix-like environments, but then they probably care independent from whether they want to use ASDF or not. Or they don't want to narrow themselves down to Unix-style environments, but then getting that overhead just for wanting to use ASDF doesn't make that much sense. In my opinion, this speaks for separating them out of ASDF (and ASDF could take advantage of them in case it detects they are present).

I know this is all difficult to set up and requires a lot of time and energy, so I also understand why you may not want to go the extra mile to work on such a separation.



Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.







More information about the asdf-devel mailing list