On 3/30/10 Mar 30 -9:29 AM, Juan Jose Garcia-Ripoll wrote: > On Tue, Mar 30, 2010 at 4:25 PM, Robert Goldman <[email protected] > <mailto:[email protected]>> wrote: > > > Question: should we raise a style warning if the user supplies a > logical pathname that does not comply with the ANSI spec? I would > prefer that we do that. > > > The first question is whether we are going to provide a logical hostname > or whether instead we will allow the user to provide a full logical > pathname translation. That is > > :logical-host "CL-PPCRE" > > versus > > :logical-path "CL-PPCRE:MY-DESIRED;SET;OF;VIRTUAL;DIRECTORIES;*.*.*" > > The latter is trickier and proner to break. If we use the former we can > provide two sets of translations
I agree. In particular, I have vague memories of differences between ACL and SBCL on how to handle the *.*.* versus *.*, but this is lost in my neural network. > > CL-PPCRE:FASL;*.*.* -> whatever binary directory > CL-PPCRE:**;*.*.* -> source directory > > So I would stay with that. > > > Question: are we going to create a logical pathname translation for > just the system sources? Or should we create also something like > > CL-PPCRE;FASLS;*.*.* > > in addition? This seems a little tricky, since it requires that we hook > into the output name rewriting logic, but probably is The Right Thing. > > > I agree, but again this can be done in a two-step process. First > convince people that the logical hostname works and only then move to > providing binary translations -- if that is ever needed, which might not > be the case. Minor suggestion: for extensibility, uniformity, etc., would a variant where we automagically create CL-PPCRE:SRC; and CL-PPCRE:FASL; be an acceptable choice? I like this for orthogonality, and because I've always been a bit unhappy using a logical pathname with just a device --- too reminiscent of Windows' C:Foo! Also, it seems like a cleaner path to allowing the user to extend the logical pathnames for the system's host. Not a big deal; just thought I would offer this as an early-stage suggestion. Best, r _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
