A CFFI -ASDF integration bug

[Robert Goldman]

Actually, a quick aside:  `gather-operation` is an unpleasing name, 
since most of our other operation subclasses are named *foo*-`op`.

Is there some way to make `gather-op` a new name, while keeping 
`gather-operation` as a (deprecated) alias for the class?  Ideally 
permitting users' method dispatch and `make-instance` usage to continue 
to function?

In the best of all worlds, I would like to make that name change, and 
then export `gather-op` (and *only* `gather-op`).



On 4 Aug 2020, at 16:35, Robert Goldman wrote:

> On 4 Aug 2020, at 16:18, Ilya Perminov wrote:
>
>> The around method will look something like this
>>
> ```
> (defmethod input-files :around ((o asdf/bundle::gather-operation) (c 
> system))
>   (unless (eq (asdf/bundle::bundle-type o) :no-output-file)
>     (append (call-next-method)
>             (remove-if-not
>                 (asdf/bundle::pathname-type-equal-function
>                      (asdf/bundle::bundle-pathname-type 
> (asdf/bundle::gather-type o)))
>                            (mappend (lambda (c) (output-files 
> 'process-op c))
>                                     (asdf/component:sub-components c  
> :type 'wrapper-file))))))
> ```
>>
>> To my taste it knows too much about ASDF guts, but maybe it is not 
>> too bad.
>
>
> I'm looking at the code now, and
>
> * `bundle-type` is exported from `asdf/bundle` (but not `asdf`) (it 
> could use a docstring if you can propose one)
>
> * So is `bundle-pathname-type`
>
> * `pathname-type-equal-function` is not exported, but it's a trivial 
> combination of `pathname-type` and `equalp`
>
> * `gather-type` is the only "really internal" function. (A block 
> comment would be nice here, too.)
>
> * `gather-operation` is *not* exported, but I think that's probably 
> wrong on our part: I don't believe there should be hidden operations.  
> If I get around to it, I will probably export it from the `asdf` 
> (really `asdf/interface`) package, unless someone has a good argument 
> for it continuing to be internal.
>
> So I don't think that is a lot of ASDF internals, especially not for 
> customizing the ASDF protocol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20200804/ddd7be64/attachment.htm>