Re: resolution of symlinks in asdf
Christophe Rhodes <[email protected]>
| Newsgroups | gmane.lisp.cclan.general |
|---|---|
| Message-ID | <[email protected]> |
Kevin Layer <[email protected]> writes: > Christophe Rhodes <[email protected]> wrote: > >>> This may be expedient, but I don't think it makes sense conceptually: >>> the location that the binary files end up at is not a property of the >>> system, > > By definition it is a property of the system--the defsystem macro > itself indirects through symbolic links. And the symbolic links are not a property of the system, they are a property of the site policy, as I said. The fact that I have an asdf system does not force me to make any symbolic links. > Furthermore, as far as I'm concerned, it is a property of any system > that is built as part of ACL, and we have many that are not. How does the number of systems you don't build as part of ACL have anything to do with this? >>> (It may, of course, be that there isn't enough >>> information around by the time the output-files method runs to put >>> them in the right place, in which case we'll need to talk again.) > > I don't see how this could work. The only pathname stored by the > defsystem macro (unless passed in by the user, not the case here) has > been resolved through a symlink. The information about the original > symlink is lost. It depends on how regular your filesystem layout is. Yes, you don't have enough information to know where the original system: as I said in the piece that you quoted. However, you may be able to reconstruct it based on the identity of the running lisp: something like (defmethod output-files :around ((o compile-op) (c source-file)) (let ((result (call-next-method))) (merge-pathnames (make-pathname :directory `(:absolute "fasl" ,(lisp-implementation-version) ,(machine-type) ,(excl::case-mode))) result))) This is kind of workaroundy, and it might well make sense to distinguish between the system-pathname and the system-truename in the information preserved by the system, so that better output-files methods can be written. Cheers, Christophe