follow-up about handling .info file and index

Robert Goldman rpgoldman at sift.info
Tue Mar 20 19:06:51 UTC 2018


On 20 Mar 2018, at 12:31, Robert Dodier wrote:

> Hi, I was asking recently about how to handle a .info file and its
> index (CL) in ASDF.
>
> What I finally settled on is this. When the operation is COMPILE-OP,
> the .info file is copied to same location where the index fasl will go
> (because the index has some code to read the .info and it assumes the
> .info is in the same place as the fasl). In the .asd file, I say
> (defsystem-depends-on "info-index") and (:info-index "foo-index") for
> the component foo-index.lisp. This seems to be working as intended.
>
> I've pasted the code I devised as a PS below. If anyone has any
> comments about it, I would be interested to hear it.
>
> I have a couple of specific questions about the code, which you can
> see in the comments. (1) In the class definition for INFO-INDEX, it
> seems to be necessary to intone (type :initform "lisp"). Is that
> actually necessary? If so, why is that? I would have expected (on
> little reason) that the parent class CL-SOURCE-FILE would supply that.
> (2) In INPUT-FILES, why doesn't (info-index-type c) yield "lisp"?
> Doesn't INFO-INDEX have an accessor INFO-INDEX-TYPE?

See answers below.
>
> I may well be very confused about simple things. Thank you for your
> patience, I appreciate it.
>
> Robert Dodier
>
> PS. info-index.lisp:
> ;; info-index.lisp -- ASDF component type for Maxima documentation 
> index
> ;; copyright 2018 by Robert Dodier
> ;; I release this work under terms of the GNU General Public License
>
> (require 'asdf)
>
> (in-package :asdf)
>
> (defclass info-index (cl-source-file)
>   ((type :initform "lisp"))) ;; ISN'T THIS INHERITED FROM 
> CL-SOURCE-FILE ??

Sure looks like it is.  This is in lisp-action.lisp in ASDF:
```
(defclass cl-source-file (source-file)
     ((type :initform "lisp"))
     (:documentation "Component class for a Common Lisp source file 
(using type \"lisp\")"))
```
>
> (defmethod perform ((o load-source-op) (c info-index))
>   (call-next-method))
>
> (defmethod perform ((o load-op) (c info-index))
>   (call-next-method))

I don't see why the above two are necessary.

>
> (defmethod input-files ((o compile-op) (c info-index))
>   (let*
>     ((foo (call-next-method))
>      ;; WHY DOESN'T THE FOLLOWING LINE WORK ??
>      ;; (bar (info-index-type c))

This is a CLOS class, not a struct, so you don't get an automatic 
`info-index-` prefixed accessor.  You need to use `(asdf:file-type c)`
>      (bar "lisp")
>      (baz (merge-pathnames (make-pathname :type bar) (first foo))))
>     (list baz)))
>
> (defmethod output-files ((o compile-op) (c info-index))
>   (call-next-method))
Again, why is this necessary?
>
> (defun silly-copy (in-file out-file)
>   (unless (equalp in-file out-file) ;; silently refuse to copy file to 
> itself
>     (with-open-file (in in-file)
>       (with-open-file (out out-file :direction :output :if-exists 
> :supersede)
>         (do ((c (read-char in nil) (read-char in nil))) ((null c))
>           (write-char c out))))))

Probably you need something like `uiop:pathname-equal` instead of 
`equalp` above.  And if there are symbolic links in the mix, you could 
have trouble.  Consider also `uiop:truename*`.  `uiop:copy-file` may be 
more efficient than your portable stream copy.


HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180320/d52e57c3/attachment.html>


More information about the asdf-devel mailing list