From: Arseny S. <am...@ic...> - 2010-03-29 06:37:18
|
Hi, there is a bug report from Timofei Shatrov: >CLISP treats Windows shortcut files (*.lnk) like symlinks. Well, I wanted >the DIRECTORY function to return the list of actual files (because >recursively walking the directories resulted in loops). At first I thought >that the :FULL keyword was what I wanted. But the true name that it returns >for the shortcut lacks the ".lnk" extension, which leads to bad things. I wrote some code to differentiate between cygwin symlinks (used in build) and ordinary windows shortcuts (relying on cygwin sources). It's about 150 lines of code. I believe these links were used by lisp more intensively before - now I see just a couple of files: builddir/full/lispinit.mem.lnk, builddir/syscalls/preload.lisp.lnk, builddir/modprep.lisp.lnk. If I remember correctly in the past all lisp files were symlinked to builddir? How actual this feature is today? -- Arseny |
From: Reini U. <ru...@x-...> - 2010-03-29 13:43:23
|
2010/3/29 Arseny Slobodyuk <am...@ic...>: > there is a bug report from Timofei Shatrov: > >>CLISP treats Windows shortcut files (*.lnk) like symlinks. Well, I wanted >>the DIRECTORY function to return the list of actual files (because >>recursively walking the directories resulted in loops). At first I thought >>that the :FULL keyword was what I wanted. But the true name that it returns >>for the shortcut lacks the ".lnk" extension, which leads to bad things. > > I wrote some code to differentiate between cygwin symlinks (used in build) > and ordinary windows shortcuts (relying on cygwin sources). It's about 150 > lines of code. > > I believe these links were used by lisp more intensively before - now I > see just a couple of files: builddir/full/lispinit.mem.lnk, > builddir/syscalls/preload.lisp.lnk, builddir/modprep.lisp.lnk. > If I remember correctly in the past all lisp files were symlinked to > builddir? How actual this feature is today? Symlinks are used by -K full to resolve duplicate files. How the symlinks are interpretated is solely a cygwin runtime issue. CYGWIN=winsymlinks is for the old behaviour, using old-style windows .lnk files Since cygwin 1.7 the default is using a shorter magic symlink file. The user has to set the env CYGWIN if a symlink cannot be resolved. See http://cygwin.com/cygwin-ug-net/using-cygwinenv.html#winsymlinks -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Sam S. <sd...@gn...> - 2010-03-29 15:05:12
|
Arseny Slobodyuk wrote: > > there is a bug report from Timofei Shatrov: > >> CLISP treats Windows shortcut files (*.lnk) like symlinks. Well, I wanted >> the DIRECTORY function to return the list of actual files (because >> recursively walking the directories resulted in loops). At first I thought :circle should take care of that. if it does not, it is a bug. >> that the :FULL keyword was what I wanted. But the true name that it returns >> for the shortcut lacks the ".lnk" extension, which leads to bad things. I think this could also be construed to be a bug. > I believe these links were used by lisp more intensively before - now I > see just a couple of files: builddir/full/lispinit.mem.lnk, > builddir/syscalls/preload.lisp.lnk, builddir/modprep.lisp.lnk. > > If I remember correctly in the past all lisp files were symlinked to > builddir? How actual this feature is today? Indeed, since 2009/08/05, we build modules without linking them over. Also, since 2007/12/10, we do not link over LISP & D files into the build directory. However, files in linking sets (boot/base/full) are often symbolic links and thus it is important that we can resolve them. |
From: Arseny S. <am...@ic...> - 2010-03-29 18:43:29
|
Hello Reini, Tuesday, March 30, 2010, 12:43:13 AM, you wrote: > Symlinks are used by -K full to resolve duplicate files. > How the symlinks are interpretated is solely a cygwin runtime issue. This functionality, in fact used only by mingw build when (freshly built) clisp needs to read some symlinked files. When building with MSVC (I didn't tried it for a long time and believe it's quite a challenge for now) it isn't used because the build occurs in source dir. But I believe, MSVC build or, say, build with `different compiler' should use the same machinery as mingw so ability of reading cygwin symlinks is important (unless Sam agrees to change `ln -s' to `cp' in such cases). > CYGWIN=winsymlinks is for the old behaviour, using old-style windows .lnk files > Since cygwin 1.7 the default is using a shorter magic symlink file. Thanks for explaining. So mingw build is in trouble. -- Arseny |
From: Reini U. <ru...@x-...> - 2010-03-29 18:52:56
|
2010/3/29 Arseny Slobodyuk <am...@ic...>: > Hello Reini, > > Tuesday, March 30, 2010, 12:43:13 AM, you wrote: > >> Symlinks are used by -K full to resolve duplicate files. >> How the symlinks are interpretated is solely a cygwin runtime issue. > This functionality, in fact used only by mingw build > when (freshly built) clisp needs to read some symlinked files. > When building with MSVC (I didn't tried it for a long time and believe > it's quite a challenge for now) it isn't used because the build occurs > in source dir. But I believe, MSVC build or, say, build with > `different compiler' should use the same machinery as mingw so ability > of reading cygwin symlinks is important (unless Sam agrees to change > `ln -s' to `cp' in such cases). > >> CYGWIN=winsymlinks is for the old behaviour, using old-style windows .lnk files >> Since cygwin 1.7 the default is using a shorter magic symlink file. > Thanks for explaining. So mingw build is in trouble. I see. So a mingw build in a cygwin terminal (aka MSYS) requires a export CYGWIN=winsymlinks And the installation requires a cp. -- Reini Urban |