Re: ASDF, Windows, symlinks

Kevin Layer wrote:
> Line 1010 contains a call to resolve-symlinks, which causes pathname
> for a system to be the resolved symlink of the file in which the
> defsystem appears (if :pathname is not specified in the defsystem
> options). 

Yup.

> Specifically, if /build/module/foo.cl is a symlink to
> /src/module/foo.cl and foo.cl uses asdf:defsystem, then as far as ASDF
> is concerned, the pathname of the module is /src/module/ and not
> /build/module/.  This means the compiled versions of source files for
> the system will go into /src/module/ and not /build/module/.

Maybe I should avoid replying to this before caffeine, but on my reading 
of the code you quoted, it's only called for the specific case of 
finding the module sources for a module defined by a defsystem form. 
*Not* for resolving individual source files within that system, nor even 
for modules-within-the-module which map onto subdirectories.

If /build/module/module.asd is a symlink to /src/module/module.asd then 
you will get the (undesirable, in your context) behaviour you refer to, 
but I can't see anywhere in my copy of asdf.lisp that would make this 
happen for individual source files - not even a call to TRUENAME.  In 
short, if you created the link farm with links to the source files and 
copies of the .asd files, I think (I haven't checked) it would probably 
work as you are expecting.  Please note I'm not implying you should find 
that an acceptable solution, just trying to be clear on the extent of 
the problem.

> The right thing to do is to change the design of ASDF to not manually
> indirect through symlinks.  That would solve the problem with Windows
> and make ASDF have predictable and reasonable behavior.
> 
> 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.

OK, it reflects concerns of free software authors ;-)  More 
grandiloquently, it's designed to ease development in the kind of 
distributed software ecosystem where any module might depend on multiple 
other modules developed by other people, it is common to want to use 
someone else's development code (by tracking their version control 
repository), and "finished" is considered a synonym for "dead"

It's simply one possible implementation of a mapping from system name to 
the place on disk where that system may be found.  The primary concern 
is that the author of system A (by definition the "owner" of A.asd) 
will not in general know where the user of his system has installed the 
systems L and M on which it depends.

* Having the user edit A.asd is not acceptable: next time they update it 
from the author's repository they will get conflicts, next time they 
push their local changes to the author he has to strip out the details 
of their disk layout before merging their change.  With enough modules 
from enough sources this is a serious concern, not just an inconvenience.

* Having the the user specify some directory or some few directories 
which are recursively searched for modules is also suboptimal: he may 
have multiple versions of L and M - perhaps, a released version and a 
development version, or a pristine HEAD and a scratch area with local 
changes.  He will probably want to specify explicitly - and will 
certainly want to know definitely - which is in use.  This tends to 
militate against any magic "use the first we find" answer, which might 
be upset by an OS upgrade, or the installation of some other software: 
far better a solution in which an explicit step is needed to switch from 
one source of L to another.

* The easiest answer which doesn't suffer from either of the preceding 
is probably something "dead simple", like a text file

((:a #p"/src/modules/a/")
  (:l #p"/scratch/hacks/for-adam/l/")
  (:m #p"/usr/local/src/lisp/m/"))

though this has problems of its own when we come to update it as new 
software is installed - everything that might change it has to agree on 
a locking strategy to protect against concurrent updates.  In the 
context of packaging system design, files "shared" between multiple 
packages are almost always bad news.

* A possible lock-free answer is to use one file per module.  Perhaps we 
could name the file consistent with the module name and have its 
contents be the pathname of the directory containing the source files.
Oops.  We appear to have reinvented the shortcut file.


Anyway, the floor is open...


-dan



-------------------------------------------------------------------------
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/