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

[Juan Jose Garcia-Ripoll]

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.

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

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100421/58b2282c/attachment.html>