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/