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.garciarip...@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
_______________________________________________
asdf-devel mailing list
asdf-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
