Zach Beane wrote:
Robert Goldman rpgoldman@sift.info writes:
Zach Beane wrote:
A few projects in quicklisp work something like this:
;;; foo.asd
(defsystem foo ...)
(defsystem foo-extra ...)
;;; bar.asd
(defsystem bar :depends-on (:foo-extra :foo))
With asdf 2, (asdf:load-system "bar") seems to work fine, I guess because asdf 2 does the equivalent of find-system on the elements from right-to-left.
With asdf 3, it doesn't seem to work fine, I guess because asdf 3 does the equivalent of find-system on the elements from left-to-right.
Are those guesses correct?
What's the best way to have a system definition that works equally well in asdf2 and asdf3 in this kind of situation?
I feel like I'm missing something. Is there some reason you can't simply make
(defsystem foo-extra :depends-on (:foo) ....)
?
If they were in separate files, yes. They aren't.
I misunderstood your original question: I thought that this was a dependency problem, but it's not. The problem is that the system authors depended on something contingent about the way FIND-SYSTEM was invoked to find depended-upon systems. I haven't gone back to check, but my guess is that something once iterated and pushed, and now collects.
This was relied upon by some projects, and now it doesn't work.
I'm sorry, but to the best of my knowledge that behavior was never offered up by ASDF to be relied upon. Programmers should not have depended on this behavior.
The only solution I know of is to break foo.asd into multiple files. I realize that this is inconvenient, but restoring backward compatibility involves restoring a state where programmers are relying on a reading that is not just contingent, but contingent in a way that encourages people to write system definitions in a way that will be actively misleading to the reader (since conventionally we read left to right).
Does this happen in enough systems in quicklisp that this is a serious problem? How many? Perhaps we can work out some solution. I realize that in many cases the one-system-per-file mapping can be a nuisance.
Best, r