asdf:defsystem complains about path, sometimes

[Mirko Vukovic]

Scales were falling of my eyes as I was reading Drew's explanation. Thank
you very much.

In my feeble defense, my expectations were based on CLISP, SBCL, and CCL's
behavior (as pointed out by the follow-up email from Vibhu).

Mirko

On Wed, Mar 1, 2017 at 11:25 AM Drew C <me at drewc.ca> wrote:

> Hey,
>
> On Wed, Mar 1, 2017 at 8:00 AM, Mirko Vukovic <mirko.vukovic at gmail.com>
> wrote:
>
> Hello,
>
> This is with asdf 3.1.7.27,
> Armed Bear Common Lisp 1.4.0
> Java 1.6.0_41 Sun Microsystems Inc.
> OpenJDK 64-Bit Server VM,
> Emacs & Slime
>
> The following example code from the ASDF manual
>
>
> The manual,
> https://common-lisp.net/project/asdf/asdf.html#The-defsystem-form,  just
> before the code, states :
>
> << Let’s look at a simple system. This is a complete file that should be
> saved as hello-lisp.asd (in order that ASDF can find it when ordered to
> operate on the system named "hello-lisp") >>
>
> This is important, as without a pathname where the system definition
> resides, how can it know where "packages.lisp" resides?
>
>
> (asdf:defsystem "hello-lisp"
>   :description "hello-lisp: a sample Lisp system."
>   :version "0.0.1"
>   :author "Joe User <joe at example.com>"
>   :licence "Public Domain"
>   :depends-on ("optima.ppcre" "command-line-arguments")
>   :components ((:file "packages")
>                (:file "macros" :depends-on ("packages"))
>                (:file "hello" :depends-on ("macros"))))
>
> when executed via the ABCL command line gives a relative path error
>
>
> Because it is looking for  #P"packages.lisp", but does not know where it
> resides.
>
> Have a look at
> https://github.com/fare/asdf/blob/90502898375fe183d96cb03cd333d8b3ec09c0ba/parse-defsystem.lisp#L21
>
> ;; The defsystem macro calls this function to determine the pathname of a
> system as follows:
>     ;; 1. If the pathname argument is an pathname object (NOT a
> namestring),
>     ;;    that is already an absolute pathname, return it.
>     ;; 2. Otherwise, the directory containing the LOAD-PATHNAME
>     ;;    is considered (as deduced from e.g. *LOAD-PATHNAME*), and
>     ;;    if it is indeed available and an absolute pathname, then
>     ;;    the PATHNAME argument is normalized to a relative pathname
>     ;;    as per PARSE-UNIX-NAMESTRING (with ENSURE-DIRECTORY T)
>     ;;    and merged into that DIRECTORY as per SUBPATHNAME.
>     ;;    Note: avoid *COMPILE-FILE-PATHNAME* because the .asd is loaded
> as source,
>     ;;    but may be from within the EVAL-WHEN of a file compilation.
>     ;; If no absolute pathname was found, we return NIL.
>
>
>   Invalid relative pathname #P"packages.lisp" for component ("hello-lisp"
> "packages")
> Restarts:
>   0: RETRY                         Retry ASDF operation.
>   1: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting
> the configuration.
>   2: TOP-LEVEL                     Return to top level.
>
> If that code is in a file, then the file compiles cleanly:
>
>
>
> As it should. It now knows where the files are located, because you have
> it in the .asd file which is LOAD'ed.
>
>
>
>
> CL-USER(6): (load (compile-file "test.asd"))
> ; Compiling /home/mv/projects/poi+excel/test.asd ...
> ; (IN-PACKAGE :CL-USER)
> ; (ASDF/PARSE-DEFSYSTEM:DEFSYSTEM "hello-lisp" ...)
> ; Wrote /home/mv/projects/poi+excel/test.abcl (0.021 seconds)
> T
> CL-USER(7):
>
> I am looking for confirmation of this and second opinions before taking up
> at the ASDF mailing list.
>
>
> Confirmed, the second option is what should be used most of the time.
> Othewrwise, the source location (:pathname) can be used to tell it where
> the source code lies without it 'guessing'. Does that all make sense?
>
> Cheers,
>
> Drew Crampsie
>
>
> Thanks,
>
> Mirko
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20170301/0f14a2ff/attachment-0001.html>