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

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Mar 29 16:05:04 UTC 2010


On Mon, Mar 29, 2010 at 5:47 PM, Robert Goldman <rpgoldman at sift.info> wrote:

> I.e., can you characterize this declaratively in terms of the values of
> MODULE-COMPONENTS, and for some operation the values of INPUT-FILES
> and/or OUTPUT-FILES?
>

I do not understand your concerns or those in other messages. I do not
intend to change the API, nor the way TRAVERSE works. I just want to code a
_separate_ function that ensures we gather everything that is needed for a
system to load. I see three uses of a better coded GATHER-COMPONENTS

1) Find the compiled files that make up a system
2) Find all the components that make up a system
3) Find all the files that make up a system

In case 1) which is the one I am most interested in the behavior should be
as follows. Assume lisp L is a fresh new image with only ASDF in it and
assume system S is the system we want to gather information about. Assume
that L is used ONCE with S using operation LOAD-OP. Exit that lisp image and
load L AGAIN and apply LOAD-OP on the same system S. GATHER-COMPONENTS
should return the list of files that are LOADed in the second phase, for
this is by definition the set of files that actually make up a system.

Case 2) could be coded as case 1) but instead of gathering the files at the
end, gather the list of all components.

Case 3) requires new syntax because right now we do not have ways to list
all the resources that belong to a system, do we?

The reason why I am calling for a consensus here is that this implies
understanding how TRAVERSE works and finding the right way to operate on the
chain of systems to gather the previous information.

Juanjo

-- 
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/c1e76c66/attachment.html>


More information about the asdf-devel mailing list