On 3/30/10 Mar 30 -12:32 PM, james anderson wrote: > > On 2010-03-30, at 19:12 , Robert Goldman wrote: > >> On 3/30/10 Mar 30 -11:52 AM, james anderson wrote: >>> >>> On 2010-03-30, at 16:25 , Robert Goldman wrote: >>> >>>> On 3/30/10 Mar 30 -5:00 AM, Juan Jose Garcia-Ripoll wrote: >>>>> [...] >>>> >>>> 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;*.*.* >>> >>> if asdf decides to befried logical pathnames, it should allow the >>> system to define its own mapping. >>> >>>> >>>> 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 had understood that the name rewriting logic is disabled for >>> logical pathnames. >>> which is as it should be. >> >> Clarification: the name-rewriting logic would still be disabled for >> logical pathnames. What I was suggesting was that >> >> <SYSTEM-NAME>:FASL; >> >> should be a logical pathname that would point to the location where >> <SYSTEM-NAME>'s (direct) fasls would be written by Faré's name >> rewriting. >> >> I.e., this would be a way for the system to find its own fasls >> reliably, >> no matter what the output name rewriting does. >> >> Is that more clear? > > yes and no. if one wants to map binary files differently that source > files, the present (last i looked) asdf behavior was adequate. the > last i looked, my binaries were at the specified locations. > my experience[1] is that it works better if the pattern matches on > the file type. given the proper mapping one neither needs nor wants > any asdf internal mapping.
I believe what Juanjo wants here is an ability to have the LOADING of the ASDF file generate some logical pathnames. So that after I asdf-load my system FOO, then code /inside/ foo could use a logical pathname like "FOO:SRC;DATAFILES;DATA1.DAT" with the guarantee that ASDF has set up the logical pathname translations for "FOO:SRC;" best, r _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
