On Wed, Apr 21, 2010 at 10:31 AM, james anderson <james.anderson@setf.de> wrote:

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.

further experiments demonstrated that - with changes to the scripts  

to account for functions which would be removed, all regression tests  

pass, and that with appropriate initialization, a multi-runtime build  

is supported for the normal abcl/acl/ccl/clisp/cmucl/ecl/lw/sbcl  

complement. 

- 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.