Bug report: COMPILE-FILE, COMPILE-FILE-PATHNAME disagree on output dir
Mark Evenson
evenson at panix.com
Wed Nov 11 15:51:18 UTC 2020
> On Nov 8, 2020, at 22:52, Robert Munyer <2433647181 at munyer.com> wrote:
[…]
> FILE-PATHNAME seems good now, but I'm still finding pathname-
> related bugs in COMPILE-FILE itself. The latest is one where it throws
> a "file ... does not exist" error while trying to compress the temporary
> files that it has just created into an archive. I'll paste a demo of
> that bug at the end of this message.
>
> If you remove this assignment statement from the source of COMPILE-FILE:
>
> (setf output-file
> (make-pathname :defaults
> (if output-file
> (merge-pathnames output-file
> *default-pathname-defaults*)
> (compile-file-pathname input-file))
> :version nil))
>
> , and replace it with this one:
>
> (setf output-file
> (compile-file-pathname input-file :output-file output-file))
>
> , then the pathname-related bugs that I've been noticing go away.
It makes a lot of sense to use COMPILE-FILE-PATHNAME now that it does what we
want. Applied as [2][] in github.com pull [355][]. Thanks for the code.
[355]: <https://github.com/armedbear/abcl/pull/355>
[2]: <https://github.com/armedbear/abcl/pull/355/commits/bbf8321f7cb58cc92148b2c8382b3c8832eeeb64>
>
> I see that the existing code is going out of its way to force the
> pathname version number to NIL. I don't know if there is a good
> reason for it to be doing that. If there is a good reason for it,
> it should be done in COMPILE-FILE-PATHNAME, not in COMPILE-FILE.
Agreed to ignore the PATHNAME-VERSION complications, until someone argues for
restoring them. I can’t think of any current filesystems that the Bear
encounters where a version would have an unambiguous meaning which would be
portable to the ones I commonly use.
best,
Mark
--
"A screaming comes across the sky. It has happened before but there is nothing
to compare to it now."
More information about the armedbear-devel
mailing list