On Nov 8, 2020, at 22:52, Robert Munyer 2433647181@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