On 22 Jan 2011, at 22:05, Faré wrote:
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?
I prefer to have a single configuration file, so I don't have to maintain different configuration files in parallel.
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.
Maybe this is where I'm misunderstanding some of the internal workings of ASDF 2. But I am seeing hard-coded physical pathnames, such as ".config/common-lisp/", all of over the place in asdf.lisp.
What am I missing?
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.
OK, good.
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.
Well, so far it only worked for me using the hack I described. I guess I'm doing something wrong...
Pascal