Faré fahree@gmail.com writes:
On 22 April 2011 09:52, Zach Beane xach@xach.com wrote:
FYI, the recent updates removing and reinstating ASDF:SYSTEM-DEFINITION-PATHNAME broke my dist construction machinery, which relied on the original behavior of that function.
How did you rely on that function?
I wanted to find the system file that would be loaded by a (find-system "foo") without loading the file first.
It doesn't always make sense, for instance with runtime-computed of "fallback" systems that are not backed by a .asd file.
Is there more than one such system, i.e. is this just a single-use hack for loading ASDF as a system?
If needed, I could possibly split find-system into subfunctions, but you'd have to deal with more than just pathnames.
I wound up changing my approach entirely. My goal was to answer the question "What systems are defined by foo.asd?" Instead of determining the filename in advance, I got it after the fact and used map-systems to find related systems defined in the same file.
Switching to ASDF:SYSTEM-SOURCE-FILE caused subtle problems for me, because functions in ASDF:*SYSTEM-DEFINITION-SEARCH-FUNCTIONS* must now return actual pathname objects, and pathname designators like strings do not suffice. (They result in a component-not-found error.)
What about returning a pathname instead of a string?
Yes, that's what I did.
In other words, I'm eager to improve ASDF to make it more suitable to your purposes, but I require more precise feedback as to what to do.
It would be nice the behavior of exported functions didn't change in subtle ways between minor releases.
Zach