Bundle operations

[Robert Goldman]

On 9/8/15 Sep 8 -2:03 PM, Faré wrote:
>>> : Faré
>>> On implementations other than ECL (and maybe also MKCL and CLASP),
>>> DLL-OP and LIB-OP will capture the outputs of extensions like CFFI,
>>> and not of the main Lisp implementation.
>>>
>>> Problem is, the extensions need to cooperate, and CFFI doesn't at this time.
>>> i.e. they need to compile to .o before they transform the .o into a .so or .a
>>> — then LIB-OP and DLL-OP can collect the .o and build a .a or .so respectively.
>>>
>>> PS: if someone fixes CFFI, they should *also* use tmpize-pathname then
>>> rename-file-overwriting-target to fix the same race condition that
>>> otherwise plagues concurrent invocations of ASDF.
>>>
>>> Is any CFFI maintainer listening?
> 
>> : Robert
>> I'm not sure I understand.  It sounds like on implementations other than
>> C-based ones, these operations will do something fundamentally
>> different.  Or am I misunderstanding?  Here's what I think you are saying:
>>
>> On ECL (and possibly others) after you do a DLL-OP, you get a system
>> that can be loaded as a DLL.
>>
>> On a "conventional lisp" after you do a DLL-OP, you get a DLL for some
>> subset of the functionality.
>>
>> So then on ECL you would have a system that you could load by loading
>> the DLL.  But on a conventional lisp, if you loaded the DLL, you'd get
>> only a subset of the functionality.
>>
>> Is that right?  If so, it seems that it would be The Wrong Thing to use
>> the same name for both things, because they don't do the same thing.
>>
> Well, the idea is as follows:
> * LIB-OP collects all the .o files for your system in a .a
> * DLL-OP collects all the .o files for your system in a .so
> 
> Now, on a C-based implementation, "all the .o files" means essentially
> all your system, whereas on other implementations, it means only C
> extensions that play the game (currently: none).
> 
> The idea is that you could always deliver a system (or a system +
> dependencies) in either one file (.fasl) or two files (.fasl and .so),
> depending on whether you're on ECL or another implementation.


I don't mean to be nitpicky, but this seems deeply wrong to me.  It
makes the semantics of the operation depend on the user's detailed
knowledge of the implementation, and does two substantially different
things:  on a C-based system it's "return me a library version of the
system," and on a conventional implementation, it's "return me a set of
ancillary files as a library".  Also, IIUC your previous email, the
notion of what happens on a non-C-based implementation, basically
doesn't work.

So right now, I think this is just an attractive nuisance on non C-based
implementations.  I'd rather not waste a user's time trying to make them
work, or my time trying to maintain them.  So I'd prefer we just disable
LIB-OP and DLL-OP on implementations where they are not known to work.
I.e., the burden of proof is a demonstration that they work, not a "you
haven't shown that they DON'T work."

That would mean these would currently be either #+ECL, or possibly #+(or
ECL MKCL) (cheap and easy) or would have guards (harder to code) with
the same semantics.  As other implementations provide support, we could
turn them on.

If someone is really passionate about having these on a non-C-based
implementation, and can make a strong case for them, which includes (1)
redefining the behavior description and (2) demonstrating that they
function correctly,  I'm open to being convinced.  But for now, they
should be shut off.