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