[asdf-devel] Cache? Translations? How to get rid of them?

[Juan Jose Garcia-Ripoll]

On Mon, Mar 15, 2010 at 2:33 AM, Faré <fahree at gmail.com> wrote:

> > directory, the *.ASD file and the binaries, is just fine.
> >
> > It's your design choice. I believe that distributing together, in the
> same
> OK. But I don't see what is your problem, then?
>
> I mean, you can either write a new component type for libraries to be
> loaded
> without being compiled (i.e. compile-op is a nop, load-op loads the
> binary),
> or just define a special method that does all the loading.
>

The problem is that this extends beyond load-op. There are currently six
other operations for six other delivery modes in asdf-ecl.lisp -- fasl,
shared and static library, monolithic or not --. The operations may depend
and use those prepackaged binaries, not because they are applied by
themselves, but because the component that they get use as input files the
"output files" of the static bundle.


> > written code.
> > We just need a way to selectively deactivate those translations from user
> Why need translations at all? Just don't use OUTPUT-FILES in your target
> .asd.
> When you create a target .asd, use components that refer directly to the
> things to be loaded. Your class compiled-file looks great.
>

DLL-OP on system A that depends on system B, which is in binary form must
look at the dependencies and see what output files they produce. B in this
case has a static library libb.a which is used by its children and this is
listed as "output-files".


> So I suppose that what you were asking for all that time,
> that I was failing to understand all along, was
> the ability for OUTPUT-FILES
> to say return a (CONS PATHNAME NIL) meaning
> "I want this pathname, untranslated"
> and the outer-most :AROUND method would detect that, then pass
> the inner PATHNAME untranslated.

That's totally doable. Would adding a case
> (cons (pathname (car path)))
> to apply-output-translations satisfy you?
>

Indeed. This or any other way that does not break current ASDF. What I would
like is seamless integration without imposing something that is prone to
break in the future. Another possibility would be for OUTPUT-FILES to return
two values: the list and an optional second value saying "do not translate!"
This second value will be ignored by existing functions but it may be used
by apply-output-translations It also has the advantage that the main output
value remains in the same format and we do not introduce a corner case that
might break ASDF's logic.


> Alternatively, I could cook up an API to easily add a mapping to
> output-translations on the fly (if not already there).
>

This could be problematic if we keep in the same tree ASDF files for
projects that are shipped in binary and in source form.

So what about marking paths as "not to be translated" by returning
> (list path) instead of path?
>

I will use whatever API you choose. Thanks again for taking your time to
read my long emails!

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100315/1ab48209/attachment.html>