[asdf-devel] summary proposal for COMMON_LISP_PATH and system search changes

Robert Goldman rpgoldman at sift.info
Tue Sep 29 14:09:58 UTC 2009

Faré wrote:
> 2009/9/27 Robert Goldman <rpgoldman at sift.info>:
>> Tobias C. Rittweiler wrote:
>>> "Pascal J. Bourguignon" writes:
> I think the questions are whether to
> 2- (semantics) whether and how to specify recursion for search in the PATH.
> The important point to discuss is 2 - especially if the path is to be
> shared between ASDF and XCVB, since (a) ASDF doesn't currently recurse
> on entries of its *central-registry*, whereas (b) XCVB does recurse on
> entries of its *xcvb-path*, and eagerly searches for entries, avoiding
> VCS caches (old svn and darcs) and detecting and discarding any
> conflicts (and this recursing is essential to the design of XCVB).
> You can see how XCVB does it there:
> http://common-lisp.net/gitweb?p=projects/xcvb/xcvb.git;a=blob;f=search-path.lisp;hb=HEAD
> Of course, (i) ASDF has a requirement of backwards compatibility, and
> (ii) recursing in a way both efficient and portable might be tricky,

I'm reluctant to add default recursion for reasons of efficiency.  I
work on a number of projects that contain both Java and CL code.
Auto-recursion fits this case particularly poorly, because the java
compiler and the namespacing conventions cause java code to excrete
directories at a ferocious pace.  Tree-searching one of these projects
is very painful.

Now, one could provide the ability to turn this behavior off, of course,
but that raises the bar to entry.  I'd prefer this recursion be turned
OFF by default, and enabled by people who know they want it.

Possible happy compromise:  allow a convention like


to specify when you want recursion in the variable?

That works for the shell variable, which is a string; not sure how to
mark the corresponding CL pathname object.


More information about the asdf-devel mailing list