"Solved" (was: Re: [asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 220.127.116.11)
david.cooper at genworks.com
Tue Oct 22 19:57:09 UTC 2013
On Tue, Oct 22, 2013 at 3:27 PM, Faré <fahree at gmail.com> wrote:
> I suppose the solution is for search-for-system-definition to treat
> sysdef-preloaded-system-search specially and put it at the end of the
> search, just like it magically puts find-system-if-being-defined
> first. For backward compatibility, we can either remove
> sysdef-preloaded-system-search from the
> *system-definition-search-functions*, or have it become a no-op, and
> have its effect magically at the end of search-for-system-definition
> under a different name.
But isn't uiop a bit of a special case? As I understand it, according to
normal use, you would indeed want preloaded-systems to come first in the
search, wouldn't you? Let's say I ship an image with cl-who built into it.
Then the downstream user loads quicklisp and asdf (which I specifically do
_not_ build into my image, but the current-version source code for which I
provide with my distribution, with a convenient function for the user to
I plan to arrange for all the built-in systems to get registered
immediately after the user loads quicklisp and asdf (of course the user
could circumvent that if she really wanted to, but by default I would think
this should be the case).
Then let's say the user next loads some library which :depends-on
(:cl-who). Since cl-who is built into the image, we really don't want
quicklisp going out and fetching it again, do we? Isn't that the whole
point of registering preloaded sytems?
Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel