Bundle operations

[Robert Goldman]

On 9/8/15 Sep 8 -12:36 PM, Faré wrote:
> On Tue, Sep 8, 2015 at 11:53 AM, Robert Goldman <rpgoldman at sift.net> wrote:
>> Are these reasonable across different Lisp implementations?
>>
>> E.g., what would it mean to try to invoke a DLL-OP on ACL, Lispworks, or
>> CCL?
>>
>> It seems like we are advertising a lot of functionality that we do not,
>> in fact, support.  I'd like to prune this down in some way, eliminating
>> operations on implementations that don't support them.
>>
> This is a trick question.
> 
> 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?
> 

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.

Cheers,
r