defmethod asdf:source-file-type does not work anymore

[mugrido]

Trying to define different file types (e.g., "cl") used to work defining the corresponding "defmethod asdf:source-file-type". Now all files are expected to be "lisp". A quick workaround that mimics the previous behavior is:

(defclass dummy-file (asdf:cl-source-file)
   ((type :initform "cl")))

(asdf:defsystem name-of-system
  :default-component-class dummy-file
...

[Robert P. Goldman (rpgoldman)]

Can you clarify why you think that this is a bug?

Is it that the signature for SOURCE-FILE-TYPE has changed:

(defgeneric source-file-type (component system))

Yes, now you need to use the TYPE initarg on source-file subtypes, which is retrieved by the reader method source-file-explicit-type. (Actually, Fare, if you look at this, is there some reason this is an accessor instead of a reader? It's only ever used as a reader, and I can't imagine we want people mutating this slot.)

I'm inclined to dismiss this as not a bug.

[mugrido (mugrido)]

On Wed, 2010-07-28 at 13:22 +0000, Robert P. Goldman wrote:
> Can you clarify why you think that this is a bug?
>
> Is it that the signature for SOURCE-FILE-TYPE has changed:
>
> (defgeneric source-file-type (component system))
>
> Yes, now you need to use the TYPE initarg on source-file subtypes, which
> is retrieved by the reader method source-file-explicit-type. (Actually,
> Fare, if you look at this, is there some reason this is an accessor
> instead of a reader? It's only ever used as a reader, and I can't
> imagine we want people mutating this slot.)
>
> I'm inclined to dismiss this as not a bug.

Hi Robert,
perhaps do you want to mention this in the documentation? Section
6.2.1.5 in http://common-lisp.net/project/asdf/asdf.html points to the
old solution.

Benjamin

[Robert P. Goldman (rpgoldman)]

Very good point, thanks. I have just pushed a patch to the manual. This won't automagically be reflected in the web page so, if you feel comfortable doing so, please pull the update, build the manual, and see if the discussion is good.

[Faré (fahree)]

Robert, your (documentation) fix is correct.

However, for the sake of posterity, I must remark that the issue is actually due to my making pathname resolution of components something eager rather than lazy.

Previously, that resolution was lazy, making things "interesting" if something depended on *default-pathname-defaults* and that variable were bound to a different value when the system was operated on from when it was defined.

Making things eager was the easiest way to make the semantics of pathnames well-defined and simple. That it broke the previous way of customizing file names was an unforeseen consequence. My apologies for the breakage.

I don't think we're going to unbreak things and support the old way of customizing pathname types for components, so unhappily this bug is as resolved as it is ever going to get. I will mention this incompatibility in the FAQ about the ASDF 1 to ASDF 2 transition.

[Robert P. Goldman (rpgoldman)]

Actually, if you have a peek at my manual patch, I did already put something into your FAQ about ASDF 1 versus ASDF 2 transition. So that's done already.

Note that I just pulled Benjamin's original proposed solution, and texinfo'ed it. So it would be good if someone would make sure I didn't introduce an error there.

[mugrido (mugrido)]

On Wed, 2010-07-28 at 18:33 +0000, Robert P. Goldman wrote:
> Actually, if you have a peek at my manual patch, I did already put
> something into your FAQ about ASDF 1 versus ASDF 2 transition. So
> that's done already.
>
> Note that I just pulled Benjamin's original proposed solution, and
> texinfo'ed it. So it would be good if someone would make sure I didn't
> introduce an error there.

The solution included in the texinfo seems to work fine for me.

Benjamin

[Faré (fahree)]

Marking as fixed.