[asdf-devel] ASDF with RMCL?

[Faré]

2011/1/22 Pascal Costanza <pc at p-cos.net>:
> The reason why I'm having problems is probably because I want to create a setup that works the same for all the Common Lisp implementations that I'm using. (I'm the maintainer of Closer to MOP, and this requires regular testing on several CL implementations, including RMCL, which is still in use by several parties.)
>
Uh, considering that RMCL has a different idea of what your
user-homedir-pathname is than unix-aware Lisps, why not just have two
sets of configuration files, one that works on Unix, and one that
works for RMCL?

e.g. in your
/Users/costanza/.config/common-lisp/source-registry.conf
you'd have paths using the Unix names with / as separator, and
in your
Macintosh HD:Users:costanza:RMCL 5.2.1:.config:common-lisp:source-registry.conf
you'd have paths using the Macintosh names with : as separator.

Is that a problem?

If you *really* want to automate conversion, then do just this —
automate conversion.

> At the moment, there are only two options to make RMCL work with ASDF 2, as far as I can tell. One is to exclusively use logical pathnames, but that requires setting up the same logical pathname translations for all the other CL implementations, as far as I can tell. (Maybe this also has other implications, but I cannot tell, because I haven't dived deeper in that direction.)
>
IIUC, ASDF2 can very well work with RMCL. The thing that mostly
doesn't work is sharing configuration files between implementations
that assume Unix-style pathnames and those that assume Mac-style
pathnames. And the easy solution is: "don't do it".

Another solution is to use idioms like this in your source-registry.conf:
(:tree (#+mcl #p"Macintosh HD:" #-mcl #p"/" "Users" "costanza" "lisp"))

> The other option is to use *central-registry*, but one goal for me was to switch to the new recommended configuration options. Referring to section 7.1 of the ASDF user manual, none of the options described there seem to work with RMCL, as far as I can tell, because ASDF 2 seems to make strong assumptions about what physical pathnames are supposed to look like (basically, Unixy), and these assumptions simply don't hold at all for RMCL.
>
No, I took enormous pains so that ASDF2 shall make no assumption what
physical pathnames look like. It either passes pathnames and
namestrings directly to the implementation, or, when defining
components, it passes pathnames directly and interprets strings using
its own portable implementation of Unixy relative pathnames.

It is conceivable that a future ASDF2 should also provide its own
portable interpretation of strings in the pathname-designators of
source-registry and output-translations. But currently, strings there
are just implementation-specific namestring (with the hope that on a
current machine, implementations should agree on the syntax, which is
not the case between RMCL and other implementations).

> I figured out a hack that is workable for me at the moment, which consists of adding the following to my init.lisp for RMCL:
>
> (let ((exp (with-open-file (s #P"Macintosh HD:Users:costanza:.config:common-lisp:source-registry.conf")
>             (read s))))
>  (labels ((traverse (exp)
>             (typecase exp
>               (cons (case (car exp)
>                       (:home (push (concatenate
>                                      'string
>                                      "Macintosh HD:Users:costanza:"
>                                      (substitute #\: #\/ (cadr exp))
>                                      ":")
>                                    asdf:*central-registry*))
>                       (t (traverse (car exp))
>                          (traverse (cdr exp)))))
>               (t '()))))
>    (traverse exp)))
>
Whatever works for you. Note that you probably want to do something
different for :tree and :directory. You could conceivably take the
result of your substitution and pass it to asdf:initialize-source-registry;
or you could have one source-registry.conf use #. to convert on the fly
from the master one.

> This converts one particular configuration file into a form that is understood by *central-registry*. The binaries are then stored in some subfolder of the RMCL folder, but that's ok. This is all not beautiful, but it works.
>
> Note that I'm not trying to put any pressure on anybody to fix this for me. I know that such portability issues are very difficult to deal with, and it's already amazing how well ASDF 2 works in that regard.
>
> But please don't remove support *central-registry* in a future version of ASDF, unless you make the rest more portable.
>
We do not intend to remove support for *central-registry* any time soon.
Maybe it'll be deprecated in ASDF3 and removed in ASDF4. Hopefully, XCVB
will replace ASDF before then, or we'll all be using R8RS Scheme, or
something.

> Any comments about what I may be missing, or suggestions for better workarounds, are of course welcome.
>
If this is the kind of issues you're having, I suppose I should be
declaring ASDF2 as now working on RMCL.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Opportunity is missed by most people because it comes dressed in overalls
and looks like work.	— T. A. Edison