On 2010-04-21, at 10:56 , Juan Jose Garcia-Ripoll wrote:
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.
in principle, yes. in detail, there is no need to construct a global structure as the computation can proceed locally.
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)
which one should be able to continue to support in any case.
- 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.
to quote from the original post.
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.
that is, the multi-runtime build included ecl. for which the expression of the functional requirements was the conditionalization in the output-files method. if that is the extent of the requirement, then ecl is taken into account.
- 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.
if the intended question was: "does the compiled file associated with 'file1.lsp' make sense without traversing the ASDF system?"
yes and no. yes, in that the output - and _input_ - location translations are computed with respect to the respective component only. no, in that system instantiation protocol includes a step which (effectively) walks the model to compute a location for each component. as i noted in the original message, this makes it a lot easier to understand a component pathname computation, but is independent of any translation mechanism. in addition, it is no longer even unique to the lp-based location translation implementation. as the step was already introduced in 1.676.