On Wed, Dec 24, 2008 at 12:00 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
ASDF has its infamous *central-registry*. gcc has /usr/include and<br>
various -I flags. then there is PERL5PATH, PYTHONPATH, etc.<br>
</blockquote><div><br>Hi Fare,<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My current thoughts: XCVB at startup initializes a path from each of<br>
the following, in order, that may either modify or replace the former:<br>
1- builtin default, say /usr/share/common-lisp/source/<br>
2- environment variable, say XCVB_PATH, : delimited, some magic entry<br>
! means splice the former value<br>
3- command-line argument, say --path, same behavior as above<br>
4- lisp configuration, say xcvb:*search-path*, a list of pathnames.<br>
</blockquote><div><br>This seems like it covers everything, but I find I lump more loading stuff in<br>deployed systems into the setup/startup script - and setting XCVB_PATH there just seems messy.<br><br>May I suggest having a xcvb:*find-modules* var (or similar) that contains a list of these functions (or<br>
symbols to these functions perhaps) so that instead of just adding new pathnames, we can add<br>functions to find lists of these pathnames. They could optionally accept a module name in case the searching module can use the information to narrow the search better.<br>
<br>An extension of this could also open the possibility of network paths for finding new modules.<br></div></div>