<div class="gmail_quote">On Wed, Apr 21, 2010 at 10:31 AM, james anderson <span dir="ltr"><<a href="mailto:james.anderson@setf.de">james.anderson@setf.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

the patch which was enclosed in the earlier message[2] demonstrated<br>
an implementation which modifies the three functions - component-<br>
pathname, input-files, and output-files, extends the function which<br>
constructs the component absolute pathname, and adds a function to<br>
map between logical and physical pathname components. [...]<br>
<div class="im">
</div>we can discuss the general utility of logical pathnames at length, at<br>
your leisure. elsewhere. my enquiry concerns whether logical pathname<br>
translations would serve as a more compact implementation mechanism<br>
for asdf output translations than the present method.<br>
<div class="im"><br>
><br>
> And even then you'll have a hard time fixing things that users<br>
> can now trivially do with the following translation:<br>
><br>
> (:root ("C:/my/cl/cache" :implementation))<br>
><br>
> This will work and make his file in<br>
>   \\remote-host\myshare\cl\cl-foo\foo-V2.000\bar_baz.lisp<br>
> be compiled as obvious from the spec into<br>
>   C:\my\cl\cache\sbcl-1.0.38-windows-x86\remote-host\myshare\cl\cl-<br>
> foo\foo-V2.000\bar_baz.fasl<br>
<br>
</div>this would appear to be the equivalent of a translation on the order of<br>
<br>
  `("**;*.*.* ,(concatenate 'string "C:/my/cl/cache/"<br>
                                    (asdf::implementation-identifier)<br>
                                    "/**/*.*.*"))<br clear="all"></blockquote></div><br>Let's try to clarify the discussion.<br><br>* 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.<br>

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

<br>I see shortcomings on both sides<br><br>- Code size<br>- A bunch of people already using asdf-binary-locations out there (which is what was merged in)<br>- 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.<br>

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

Is this it?<br><br>Juanjo<br><br>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://tream.dreamhosters.com">http://tream.dreamhosters.com</a><br>