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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.