SYSTEM-DEFINITION-PATHNAME returns nil for second of two defsystems in same .asd file

[Tobias C. Rittweiler]

;;; foo.asd
(in-package :cl-user)
(asdf:defsystem :foo)
(asdf:defsystem :foo-test)

;;; linked into registry

CL-USER> (asdf:load-system :foo)
; loading system definition from /home/tcr/.sbcl/systems/foo.asd into
; #<PACKAGE "ASDF0">
; registering #<SYSTEM :FOO {B043A99}> as FOO
; registering #<SYSTEM :FOO-TEST {B1737F9}> as FOO-TEST
NIL
CL-USER> (asdf:load-system :foo-test)
NIL
CL-USER> (asdf:system-definition-pathname (asdf:find-system "foo"))
#P"/home/tcr/.sbcl/systems/foo.asd"
CL-USER> (asdf:system-definition-pathname (asdf:find-system "foo-test"))
NIL
CL-USER>

Why does the last form return NIL?

On related note: Are the circumstances documented when SYS-DEF-PATHNAME
may return NIL?

[Robert P. Goldman (rpgoldman)]

Some asdf archaeology:

The *defined-systems* hash table has values that are pairs, reading through register-system:
the first element of which is a universal-time and the second element of which is a system object (I will submit a patch that adds a docstring for this table; this information should be available proximally to the variable definition).

AFAICT, when system-definition-pathname is called, it first tries to find a system definition through the search functions. That will fail for the system that is not the one that corresponds to the file name. The next thing it does is find the entry in *defined-systems*.

OK, this means that either it's not finding the foo-test system in the *defined-systems* table, or it's finding it, and the system-source-file is nil.

I'm not sure why this should be happening. When I look at my copy of the defsystem macro, there's a call to %set-system-source-file that should be recordingin this information. However, there is something funny going on in defsystem where it looks almost like that first system definition will be thrown away and destroyed in favor of a new object created by parse-component-form....

I don't claim to understand what's going on inside defsystem.

[Faré (fahree)]

Is this really a blocker for ASDF 2?

If not, can we create a milestone ASDF 2.1 or ASDF 3 or something? I apparently lack rights to create a new milestone.

[Stelian Ionescu (sionescu)]

On Fri, 2010-03-19 at 19:56 +0000, Faré wrote:
> Is this really a blocker for ASDF 2?

IMO it is, because SYSTEM-DEFINITION-PATHNAME is used by FIND-SYSTEM and
people rely on FIND-SYSTEM(or SYSTEM-RELATIVE-PATHNAME which ends up
calling FIND-SYSTEM) to locate resources contained in the source
directory

> If not, can we create a milestone ASDF 2.1 or ASDF 3 or something? I
> apparently lack rights to create a new milestone.
>

I'll try to fix your permissions

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

[Faré (fahree)]

Using ASDF 1.659 and cl-launch 2.901, I cannot reproduce this problem with any of the 5 implementations I have on my machine.

for lisp in sbcl ccl ecl gclcvs lispworks ; do
  cl-launch -l $lisp -s foo -ip '(asdf:system-definition-pathname :foo-test)'
done

I manage to crash clisp with ASDF 1.658, though, but it seems to me that was bug hot upgrading from 1.627, that I solved by adding system-source-file in the fmakunbound list. GCL also seems happier this way.

[Faré (fahree)]

There is no "unable to reproduce" status, so I'm marking this bug as "Fix Released" instead.

Please re-open if you keep having any trouble with this issue.

[Stelian Ionescu (sionescu)]

On Tue, 2010-03-23 at 03:57 +0000, Faré wrote:
> There is no "unable to reproduce" status, so I'm marking this bug as
> "Fix Released" instead.
>
> Please re-open if you keep having any trouble with this issue.

I think that the closest to "Unable to reproduce" is "Invalid"

--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib