[asdf-devel] 2.014.8

[Zach Beane]

Faré <fahree at gmail.com> writes:

> On 22 April 2011 09:52, Zach Beane <xach at 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