[asdf-devel] ASDF 2.0 requirements : simplify the output locations mechanism

[james anderson]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100421/969d1679/attachment.html>