"Solved" (was: Re: [asdf-devel] (asdf:system-source-directory :uiop) not working after upgrade to 3.0.2.25)

[Dave Cooper]

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
load them).

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?




-- 
My Best,

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...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20131022/c90a8aee/attachment.html>