On Wed, Apr 21, 2010 at 10:31 AM, james anderson james.anderson@setf.dewrote:
the patch which was enclosed in the earlier message[2] demonstrated an implementation which modifies the three functions - component- pathname, input-files, and output-files, extends the function which constructs the component absolute pathname, and adds a function to map between logical and physical pathname components. [...] we can discuss the general utility of logical pathnames at length, at your leisure. elsewhere. my enquiry concerns whether logical pathname translations would serve as a more compact implementation mechanism for asdf output translations than the present method.
And even then you'll have a hard time fixing things that users can now trivially do with the following translation:
(:root ("C:/my/cl/cache" :implementation))
This will work and make his file in \remote-host\myshare\cl\cl-foo\foo-V2.000\bar_baz.lisp be compiled as obvious from the spec into C:\my\cl\cache\sbcl-1.0.38-windows-x86\remote-host\myshare\cl\cl- foo\foo-V2.000\bar_baz.fasl
this would appear to be the equivalent of a translation on the order of
`("**;*.*.* ,(concatenate 'string "C:/my/cl/cache/" (asdf::implementation-identifier) "/**/*.*.*"))
Let's try to clarify the discussion.
* Fare insists on the validity of the current pathname translation mechanism, which allows the user to specify the destination of compiled files using physical pathnames and some configuration file or S-expr. If the user knows where the original file lived, he can find where the compiled file lives easily -- one to one mapping, no ambiguity, no names changes except mapping everything to a new tree.
* James is claiming that this can be implemented using _internally_ logical pathnames with a logical pathname tree structure that is constructed from the component names and not from the physical location of the files they represent. This would be complemented with a function to obtain the actual location of compiled files given the component object. The configuration can be mapped to this structure and the overall implementation would then be smaller.
I see shortcomings on both sides
- Code size - A bunch of people already using asdf-binary-locations out there (which is what was merged in) - James' implementation only seems to allow one file per component and it does not seem to take into account when OUTPUT-FILES returns more than one file. - In James's model the interrogation: where does the compiled file associated to "file1.lsp" does not make sense without traversing the ASDF system and locating that file and its associated component.
Is this it?
Juanjo