Recently I noticed that in CMUCL the following does not work:
* (compile-file "junk/foo" :output-file "junk/bin/foo.x86f")
Type-error in KERNEL::OBJECT-NOT-SIMPLE-STRING-ERROR-HANDLER:
NIL is not of type SIMPLE-STRING
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
(LISP::PICK-BACKUP-NAME 1 NIL)[:EXTERNAL]
0]
The reason is that the pathname of the output file winds up with an
extra leading directory prepended to it, which can be seen in the backtrace:
1: (LISP::FD-OPEN #p"junk/junk/bin/foo.x86f" :OUTPUT #<unavailable-arg> T ...)
Someone said that this behavior was required by the standard, because
the defaults for the output file were supposed to be merged from the
input file. Actually what the standard says is that the pathnames are
supposed to be formed like COMPILE-FILE-PATHNAME does, and that says:
The defaults for the output-file are taken from the pathname that
results from merging the input-file with the value of
*default-pathname-defaults*, except that the type component
should default to the appropriate implementation-defined default
type for compiled files.
This all seems really unintuitive to me and breaks what would seem to
me to be a very common usage:
(compile-file "src/foo" :output-file "bin/foo")
The pathname that results, seen from the backtrace, is:
(LISP::FD-OPEN #p"src/bin/foo.x86f" :OUTPUT #<unavailable-arg> T ...)
This seems obviously bogus to me. Is this behavior really required by
the standard?
BTW, just for reference I tried it in ACL6.2, and both the above
work the way I'd expect:
CL-USER(1): (compile-file "junk/foo" :output-file "junk/bin/foo.fasl")
;;; Compiling file junk/foo.lisp
<stuff left out>
;;; Writing fasl file /export/u1/homes/gilham/lisp/junk/bin/foo.fasl
Warning: No IN-PACKAGE form seen in /export/u1/homes/gilham/lisp/junk/foo.lisp.
(Allegro Presto will be ineffective when loading a file having no IN-PACKAGE
form.)
;;; Fasl write complete
#p"/export/u1/homes/gilham/lisp/junk/bin/foo.fasl"
T
T
CL-USER(2):
CL-USER(1): (compile-file "src/foo" :output-file "bin/foo.fasl")
;;; Compiling file src/foo.lisp
<stuff left out>
;;; Writing fasl file /export/u1/homes/gilham/lisp/junk/bin/foo.fasl
Warning: No IN-PACKAGE form seen in /export/u1/homes/gilham/lisp/junk/src/foo.lisp.
(Allegro Presto will be ineffective when loading a file having no IN-PACKAGE
form.)
;;; Fasl write complete
#p"/export/u1/homes/gilham/lisp/junk/bin/foo.fasl"
T
T
CL-USER(2):
--
Fred Gilham ······@csl.sri.com
It's not when people notice you're there that they pay attention; it's
when they notice you're *still* there. --- Paul Graham
In article <·················@snapdragon.csl.sri.com>,
Fred Gilham <······@snapdragon.csl.sri.com> wrote:
> Recently I noticed that in CMUCL the following does not work:
>
>
> * (compile-file "junk/foo" :output-file "junk/bin/foo.x86f")
>
> Type-error in KERNEL::OBJECT-NOT-SIMPLE-STRING-ERROR-HANDLER:
> NIL is not of type SIMPLE-STRING
> [Condition of type TYPE-ERROR]
>
> Restarts:
> 0: [ABORT] Return to Top-Level.
>
> Debug (type H for help)
>
> (LISP::PICK-BACKUP-NAME 1 NIL)[:EXTERNAL]
> 0]
>
>
> The reason is that the pathname of the output file winds up with an
> extra leading directory prepended to it, which can be seen in the backtrace:
>
> 1: (LISP::FD-OPEN #p"junk/junk/bin/foo.x86f" :OUTPUT #<unavailable-arg> T
> ...)
>
>
> Someone said that this behavior was required by the standard, because
> the defaults for the output file were supposed to be merged from the
> input file. Actually what the standard says is that the pathnames are
> supposed to be formed like COMPILE-FILE-PATHNAME does, and that says:
Yes, this is required. See the writeup of the
COMPILE-FILE-OUTPUT-FILE-DEFAULTS cleanup issue.
The idea is that you can do something like:
(compile-file some-pathname :output-file ".x86f")
to get it to put the output file in the same directory as the input,
with the same name and the .x86f type.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Fred Gilham wrote:
>
> ...
>
> Someone said that this behavior was required by the standard, because
> the defaults for the output file were supposed to be merged from the
> input file. Actually what the standard says is that the pathnames are
> supposed to be formed like COMPILE-FILE-PATHNAME does, and that says:
>
> The defaults for the output-file are taken from the pathname that
> results from merging the input-file with the value of
> *default-pathname-defaults*, except that the type component
> should default to the appropriate implementation-defined default
> type for compiled files.
>
one approach which has shown some success is to work with logical pathnames
and to map a logical binary type explicitly. this makes it possible, for
example to generate a binary tree - and even runtime-, and/or version-specific
binary trees - from the same source file designators, just by changing the
logical host definition.
http://www.cl-xml.org/sysdcl.lisp
demonstrates one way to do this.
...