> 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?