Re: ASDF, Windows, symlinks

Richard M Kreuter <[email protected]> Fri, 15 Feb 2008 18:35:41 -0500
Newsgroups gmane.lisp.cclan.general
Message-ID <[email protected]>
Kevin Layer <[email protected]> writes:

> I'll end with a question.  Since something drove the authors of ASDF
> to make the design choice they did, can someone shed some light on
> what it was?  As is often the case with bad design choices, there is
> sometimes a better solution.  Perhaps the original problem can be
> framed here so that we can all help think of a better solution than
> what we have.

The symlink resolution is there to support a specific way of using
ASDF.  I suspect that the authors didn't think of the use case
involving a tree of symlinks, or didn't consider it important.  In any
case, it's possible to control where compiled files go by supplying a
custom method for ASDF:OUTPUT-FILES, so you need not build a tree of
symlinks to keep outputs separate from inputs.

That said, the default system search function,
SYSDEF-CENTRAL-REGISTRY-SEARCH, traverses a list of directories
looking for .asd files.  If all you have is a directory of .asd files,
you need to figure out where the sources are.  Rather than requiring
the user to encode the location of the sources in the .asd file
itself, the authors of ASDF decided to encode that information in a
symlink.  Unfortunately, they baked the symlink resolution into the
DEFSYSTEM macro itself, with the consequence that your usage scenario,
a tree of symlinks into sources, has never been supportable, even if
you use a different system search function.

Now, I think it's worth pointing out that any change to ASDF that
moves symlink resolution out of ASDF:DEFSYSTEM will not be upwardly
compatible for people who use a custom system search routine that
relies on the symlink resolution inside ASDF:DEFSYSTEM.

Now, if people are willing to break compatibility that way, I think
that the following three changes would improve things:

(1) to move the symlink resolution out of DEFSYSTEM and into
    SYSDEF-CENTRAL-REGISTRY-SEARCH,

(2) to have FIND-SYSTEM bind a special, say, *SYSDEF-PATHNAME*, to
    whatever pathname SYSTEM-DEFINITION-PATHNAME returns,

(3) to have DEFSYSTEM use *SYSDEF-PATHNAME*, rather than
    *LOAD-TRUENAME*, to initialize the system's PATHNAME slot.

This way, if you use *CENTRAL-REGISTRY*/SYSDEF-CENTRAL-REGISTRY-SEARCH
FIND-SYSTEM will return a system object whose PATHNAME is the
directory containing the symlink's target, but other search functions
can be written that have different consequences for FIND-SYSTEM, e.g,

(defun default-pathname-defaults-search (system-name)
  (let* ((name (asdf::coerce-name system-name))
         (pathname (make-pathname
                    :defaults *default-pathname-defaults*
                    :name name :type "asd" :version :newest
                    :case :local)))
    ;; PROBE-FILE resolves symlinks on some implementations, so don't
    ;; return what PROBE-FILE does, but just use it as an indicator of
    ;; whether the file exists.
    (when (probe-file pathname)
      pathname)))

Regards,
Richard


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/