[Cffi-devel] [Asdf-devel] native-namestring in asdf/cache:normalize-namestring?

[Faré]

Dear Orivej,

I believe this is a bug in CFFI, and ASDF cannot do much about it. I'm
copying the CFFI-devel mailing-list.

I'm not convinced that these pathnames with invalid namestring would
have a valid native-namestring (did you try?), and using
native-namestring in asdf/cache:normalize-namestring would be quite
impractical, since the function CL:FILE-WRITE-DATE that we
subsequently use requires a Lisp namestring.

The correct thing to do would be for CFFI to assume ASDF3 (which has
been out for almost 2 years and has since been adopted by all
maintained implementations), and use this definition:

(defun exe-filename (defaults)
   (let ((defaults (uiop:ensure-pathname defaults :namestring :native
:want-non-wild t :want-file t))) ;; YMMV
      (uiop:subpathname defaults (uiop:parse-unix-namestring
(pathname-name defaults) :type *exe-extension*)))

NB: if ASDF3 is adopted, the #+sbcl and other such kluges in cffi.asd
could also be replaced by :if-feature :sbcl, the defmethod for
operation-done-p should be dropped, and the defmethod perform could be
replaced by:
   (defsystem "cffi" ...   :in-order-to ((test-op (test-op "cffi-tests"))))
and cffi-tests could similarly use an inline method :perform (test-op
(o c) ...) instead of a defmethod.

PS: the reason why SBCL (and many other implementations) have
unprintable pathnames is because of the read-write consistency
requirements for pathnames, which for the CLHS (see *print-readably*
entry) specifies must be WRITE-n in a way that they must be read back
as a "similar" object, which section 3.2.4.2.2 specifies as
component-wise similarity, so that (make-pathname :name "foo.bar"
:type nil) MUST NOT have the same readable representation as
(make-pathname :name "foo" :type "bar").

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
                — Isaac Asimov



On Tue, Nov 25, 2014 at 11:24 AM, Orivej Desh <c at orivej.org> wrote:
> Currently, between CFFI-GROVEL and ASDF, neither normalizes pathnames
> with a dot in :NAME and NIL in :TYPE.
>
>
>      (cffi-grovel:grovel-file "grovel.cffi")
>
> in a system definition may cause an error under SBCL in
> ASDF/CACHE:NORMALIZE-NAMESTRING when it calls NAMESTRING on
> the value of CFFI-GROVEL::EXE-FILENAME:
>
> Calling
>
>      (cffi-grovel::exe-filename #p"grovel.cffi.lisp")
>
> returns
>
>      #<pathname (with no namestring)
>                 :HOST #<sb-impl::unix-host {10002ACE43}>
>                 :DEVICE nil
>                 :DIRECTORY (:relative ".")
>                 :NAME "grovel.cffi"
>                 :TYPE nil
>                 :VERSION :newest>
>
> to ASDF/ACTION:COMPUTE-ACTION-STAMP which can't deal with it when called
> with :JUST-DONE NIL.
>
> Backtrace: http://report.quicklisp.org/cl-libssh2/2014-09-26/failtail.txt
>
> One solution is to make CFFI-GROVEL::EXE-FILENAME normalize resulting
> pathname: https://github.com/cffi/cffi/pull/52
>
> Another is to make ASDF/CACHE:NORMALIZE-NAMESTRING call
> NATIVE-NAMESTRING instead of NAMESTRING.
>
> Who should be responsible for normalizing such a pathname, ASDF
> of CFFI-GROVEL?
>