A modest proposition: DEFSYSTEM-DEPENDS-ON should die [was Re: What's the right way to extend ASDF with new symbols?]
Robert Goldman
rpgoldman at sift.net
Mon Feb 15 21:12:42 UTC 2016
On 2/15/16 Feb 15 -3:06 PM, Stelian Ionescu wrote:
> On Mon, 2016-02-15 at 14:48 -0600, Robert Goldman wrote:
>> Trying again:
>>
>> Can someone please state what it is that Quicklisp needs?
>>
>> IIUC Quicklisp does *something* with .asd files that does not involve
>> the defsystem-depends-on being resolved.
>>
>> Is this reading? Or loading?
>>
>> If it's loading, then the DEFSYSTEM-DEPENDS-ON entries are resolved by
>> REGISTER-SYSTEM-DEFINITION, so the status quo doesn't solve the problem
>> of large scale analysis without side-effects.
>>
>> If it's reading, then my solution is benign.
>>
>> At least as far as I can tell.
>>
>> Can someone give me a clue here?
>
> Quicklisp needs to compute the complete dependency graph between
> systems, given a set of .asd files. I'd like to extend the current Slime
> integration to search for systems in all registered .asd files and
> autocomplete. All sorts of things become possible if one could treat a
> set of .asd files as a database, with the guarantee that querying would
> never trigger a compile-file operation, ever.
>
If that's the case, then I believe that the existing implementation
*already* fails your requirement.
When you register an ASDF system, the DEFSYSTEM-DEPENDS-ON dependencies
must be loaded (and therefore, possibly compiled). ASDF needs to do
this to parse the defsystem form correctly.
So I think that we may have been arguing over nothing.
Thanks,
r
More information about the asdf-devel
mailing list