On Mon, Mar 15, 2010 at 2:33 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
> directory, the *.ASD file and the binaries, is just fine.<br><div class="im">
><br>
</div>> It's your design choice. I believe that distributing together, in the same<br>OK. But I don't see what is your problem, then?<br>
<br>
I mean, you can either write a new component type for libraries to be loaded<br>
without being compiled (i.e. compile-op is a nop, load-op loads the binary),<br>
or just define a special method that does all the loading.<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> written code.<br>
</div>> We just need a way to selectively deactivate those translations from user<br>Why need translations at all? Just don't use OUTPUT-FILES in your target .asd.<br>
When you create a target .asd, use components that refer directly to the<br>
things to be loaded. Your class compiled-file looks great.<br></blockquote><div><br>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". <br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So I suppose that what you were asking for all that time,<br>
that I was failing to understand all along, was<br>
the ability for OUTPUT-FILES<br>
to say return a (CONS PATHNAME NIL) meaning<br>
"I want this pathname, untranslated"<br>
and the outer-most :AROUND method would detect that, then pass<br>
the inner PATHNAME untranslated. </blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
That's totally doable. Would adding a case<br>
(cons (pathname (car path)))<br>
to apply-output-translations satisfy you?<br><div class="im"></div></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Alternatively, I could cook up an API to easily add a mapping to<br>
output-translations on the fly (if not already there).<br><div class="im"></div></blockquote><div><br>This could be problematic if we keep in the same tree ASDF files for projects that are shipped in binary and in source form. <br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So what about marking paths as "not to be translated" by returning<br>
(list path) instead of path?<br></blockquote></div><br>I will use whatever API you choose. Thanks again for taking your time to read my long emails!<br><br>Juanjo<br clear="all"><br>-- <br>Instituto de Física Fundamental, CSIC<br>
c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com">http://juanjose.garciaripoll.googlepages.com</a><br>