[asdf-devel] Ordering of system :depends-on elements

[Faré]

If quicklisp can't use / in names, it's probably a bug, since such
names have always been accepted by ASDF (though not actually used
before). Nevertheless, a workaround is for a system do have the
dependency on foo both before and after that on the thing that is
loaded when loading foo.asd:
   :depends-on (foo ... foo-extra ... foo)
That's ugly, and probably an abuse.

As for stripping the /, currently it's done by the individual functions in
*system-definition-search-functions* by calling primary-system-name.
I suppose that could be changed, but the backward-compatible way
would be to (let ((name ...) #+asdf3 (name (primary-system-name name))) ...)

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Foreign aid might be defined as a transfer from poor people in rich countries
to rich people in poor countries. — Douglas Casey



On Mon, Jul 8, 2013 at 11:11 AM, Zach Beane <xach at xach.com> wrote:
> Zach Beane <xach at xach.com> writes:
>
>>> So can you make suggestions about how to be quicklisp-compatible while
>>> making it possible to have multiple findable system definitions in a
>>> single file?
>>
>> Hmm, I think it might be workable if, when a system with a given slashed
>> name is not found, the *system-definition-search-functions* chain was
>> called recursively with the truncated name, instead of having each
>> function in *s-d-s-f* have to know how to truncate on its own.
>>
>> E.g. imagine I had something like this:
>>
>>   (push (lambda (name) (print (list 'trace name)) nil)
>>         *system-definition-search-functions*)
>>
>> Then it would be nice if the ASDF internals led to putput like this:
>>
>>   (find-system "foo/bar")
>>
>>   (TRACE "foo/bar")
>>   (TRACE "foo")
>>
>>   => #<SYSTEM "foo/bar">
>>
>> Does it work that way now? I don't think it does.
>
> Actually, another option could be to ONLY call the *s-d-s-f* chain on
> the truncated name. That would preclude those functions from
> implementing some new funky logic for slashed names, but I don't think
> that's really much of an issue.
>
> Zach