[asdf-devel] SBCL port of ECL's extensions

[Robert P. Goldman]

The idea of shipping an unguaranteed extension is fine with me. Let me  
just clarify, please: my concern was what seemed like a requirement  
for getting the component-gathering right. I'd rather not expose that  
to "outsiders" until we can get it right, and I'm worried, based on my  
experience with TRAVERSE, that we'd end up locked into some bug- 
compatibility.

Sounds like there's a good function that can be exposed as an  
extension without needing to get the component-gathering right, which  
would be great.

Maybe I got misled -- are there two issues: what can be done now and  
what we could do a lot better if component gathering worked reliably?

On Mar 29, 2010, at 13:43, Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com 
 > wrote:

> Hi Robert,
>
> I must say that I understand your concerns which are just, right  
> now, *time*. And I also understand that in prolonging this thread I  
> risk you lose your patience with a feeling that I am wasting your  
> time, but please read this email and understand the following key  
> points that indeed will save us all some time
>
> 1) We have a working set of ASDF extensions that ECL users apply  
> routinely to most systems out there. It works.
>
> 2) You asked me to extend those extensions to SBCL in an email to  
> the mailing list. I did it in a way that DOES NOT CHANGE the way  
> ASDF behaves in any single way (*)
>
> 3) Those extensions can be shipped with ASDF without warranty of  
> 100% work, and an explicit statement such as the following one:
>
> The asdf-bundle operations are only designed to work with systems  
> that contain basic ASDF operations and components. The protocol for  
> systems that rely on external resources, such as shared libraries,  
> compiled C files, bitmaps, etc, is not yet defined, so using it on  
> such systems is not guaranteed to work.
>
> 4) Given this, the current implementation just works. No work on  
> implementors to do before ASDF 2.0
>
> 5) In order to remove the statement of 3) we have to code a better  
> map-over-ASDF or gather-components function. This can be done at any  
> time and it is not a requirement for shipping the current  
> extensions. This was what I said should be "discussed", but if you  
> are too busy, simply forget it.
>
> You can stop reading here if you wish, and I will continue in a  
> separate email with a discussion of how this should be completed if  
> there is ever a desire to include these features in ASDF.
>
> Juanjo
>
> (*) Only a small :around method for operation-done-p, but this  
> method is only active when "performing" one of the bundle operators.
>
> -- 
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100329/a38f2d26/attachment.html>