2011/1/22 Pascal Costanza pc@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