Faré <[email protected]> writes: > On 22 April 2011 09:52, Zach Beane <[email protected]> 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 _______________________________________________ asdf-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
