On 3/29/10 Mar 29 -11:05 AM, Juan Jose Garcia-Ripoll wrote:
On Mon, Mar 29, 2010 at 5:47 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@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
- Find the compiled files that make up a system
- Find all the components that make up a system
- 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.
Thanks, that helps. But it isn't really what I'm asking, which is "how would you characterize this in terms of existing ASDF functions (I think MODULE-COMPONENTS, INPUT-FILES, OUTPUT-FILES and, given what you've said, IN-ORDER-TO). I'm not trying to be pedantic, but we are allowing people to extend the ASDF object model by creating their own components and operations. So we need to understand what implications this new GATHER-COMPONENTS is to have on extensions.
Note that your definition of GATHER-COMPONENTS is made in terms of operations that are done outside the lisp itself. So I don't think it is well-defined in terms of ASDF operations (asdf is not set up to support, for example, "pretending" that it hasn't loaded a system). Without such a clear definition, that doesn't appeal to outside operations like "start a fresh lisp," we do not have a clear specification for implementing GATHER-COMPONENTS.
Note that this would /not/ be true if we were to implement GATHER-COMPONENTS by actually starting up a separate, clean lisp process, and harvesting information out of that lisp process. If we were to do that, then your definition would be sufficient as a specification.
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?
it's not even clear what is meant by "all the resources that belong to a system." Let's return to my protocol example. Consider, for the sake of example, that I have ".proto" files that are translated, using a perl script, into ".lisp" files (call this 'proto-to-lisp-op). Now I have a system that contains a component like this:
(:proto-file "IRC-proto")
and we specify that we must perform a proto-to-lisp-op to generate IRC-proto.lisp from IRC-proto.proto before we can do the COMPILE-OP.
What's the resource here? Is it the .proto file? the .lisp file? Which should be returned for your use case #3?
This is what I mean by "extending the API," although "API" might be wrong there. Maybe "protocol" is meant. People generating .asd files have had no reason to think about this question of "resource" that you are raising here, so it's quite likely that adding this new facility will not work on previously-existing systems.
That is the reason that I'm arguing for pushing this out into ASDF 3.
Note also that this will be much easier to do if a more declarative ASDF (where dependencies needed for system definition loading are made declarative, instead of requiring calls to asdf:oos in .asd files, etc.), so that would be another reason to push this into ASDF 3.
best, r