#14 mk-defsystem illegal device in pathname

[Lennart Staflin]

Using the mk-defsystem included in common-lisp-
controller and sbcl from cCLan (rebuild from source) I
get the following when trying to use mk-defsystem:

This is SBCL 0.6.12.21, an implementation of ANSI Common
Lisp.
[..]
More information on SBCL is available at <http://
sbcl.sourceforge.net/>.
* (load "simple.system")

T
* (make:oos :simple :compile)

debugger invoked on condition of type TYPE-ERROR:
The value :ABSOLUTE is not of type (OR BASE-STRING #).
[..]
restarts:
0: [ABORT ] Reduce debugger level (leaving
debugger).
1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT
loop.
("DEFUN MAKE-PATHNAME" 369097462 10)[:OPTIONAL]

Where simple.system:

(make:defsystem "simple"
:source-extension "lisp"
:components (
(:file "foo")))

I tried to debug it a little and it seems that it calls
make-pathname with ':device :absolute' and the SBCL
make-pathname does not like that. (ANSI-CL does not say
that :ABSOLUTE is a legal device, but it allows system
specific values for device.)

[Christophe Rhodes]

Logged In: YES
user_id=133801

I can confirm this.

Firstly, the above works fine in cmucl.

Secondly, um.

In defsystem.lisp, there is:

#+(or :sbcl (and :CMU (not (or :cmu17 :cmu18))))
:absolute
#-(or :sbcl (and :CMU (not (or :cmu17 :cmu18))))
(let ((dev (component-device component)))
(if dev
(pathname-device dev)
(pathname-device pathname)))

in component-full-pathname-i, which, if sbcl doesn't believe
in keyword devices, is going to break.

The reason this hasn't yet bitten us is that that code
doesn't get executed when dealing with logical pathnames.

As a quick fix, change the :absolute in the above to
:unspecific; I don't actually understand the logic behind
putting sbcl in those conditionals (note that the
conditional is for CMU _earlier_ than 17) and probably the
correct fix is to remove sbcl from the conditional lines
I've posted above.

Hope that helps,

Christophe

[Peter Van Eynde]

Logged In: YES
user_id=7267

Will be fixed in the next release

[Christophe Rhodes]

Logged In: YES
user_id=133801

I'm fairly sure this is fixed in the current cCLan versions.
Do please let us know if you think otherwise.

Cheers,

Christophe