Hey,

On Wed, Mar 1, 2017 at 8:00 AM, Mirko Vukovic mirko.vukovic@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@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/p...

;; 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

Interesting. CLISP and SBCL can evaluate (defsystem ...), but CCL, ECL, ABCL can't.

This is how I see things.

Lisp "forms" are those S-Expressions that can be evaluated. 3 (+ 3 4) are S-Expressions that are forms, but (3) is one that isn't.

I have only ever assumed that (defsystem ...) was an S-Expression, and not necessarily a Lisp form. I make use of the (defsystem ...) in a *.asd file by calling: (asdf:operate 'asdf:load-op "...") or (ql:quickload "...")

I don't know that (defsystem ...) : a) is a lisp form at all, that can be evaluated by typing it in directly or by loading its containing file b) even if it is a form, whether it expects #'asdf:operate to set things up in a particular way before evaluating it.

So I don't know that what you're trying to do is supported by asdf. If you know that it's meant to be, then you've found a bug.

Vibhu