just some brief thoughts on this (rather than actual solutions). I am
not currently working with on the Windows installer script yet (neither
the old one on master nor the new one from the Windows branch).
Quoting Elliott Slaughter (elliottslaughter@...):
> While the Windows build itself works out-of-the-box on my system, building
> the installer for the binary requires manual intervention. These are minor
> annoyances, and they can all be worked around manually. The main risk from
> them being there is that I'll create a degenerate Windows build by accident
> if I forget anything. Some of these cause silent failures which are only
> apparent after installing the installer and testing manually.
> At any rate, publishing this list will help anyone who wants to replicate
> my Windows build on their own machine.
> 1. The contrib tests on Windows leave the contrib/sb-posix/test-output
> directory after the build is done. Delete this directory or else the
> installer build will abort. This has been the case for at least 6 months
How about adding "test-output" to *ignored-directories*?
> 2. The contrib tests on Windows name some files incorrectly.
> Specifically, contrib/sb-bsd-sockets/TEST-PASSED
> and contrib/sb-introspect/TEST-PASSED should be lowercase, not uppercase.
The recent change trigging this problem is that we are writing some of
these files from Lisp (as opposed to a shell script), which means that
they are now affected by the same problem as, for example, the fasls.
> As a result, the installer, which looks for lowercase test-passed files in
> each directory, will think these contribs failed to build, and won't
Arguably that is a bug in DIRECTORY.
Common sense says that a function matching pathnames on a case
insensitive filesystem ought to do that in a case insensitive fashion,
which our DIRECTORY does not seem to be doing.
But I am not a pathname expert at all, and common sense does not
generally factor into thoughts on Common Lisp pathnames. I have tried
Allegro and OpenMCL for comparison. Allegro, as ever so often, does the
user-friendly thing -- it is case insensitive. OpenMCL is case
sensitive, but I would not know whether that is intentional.
(One might also argue that it is hard to check how "the" filesystem
treats case, since Windows might be accessing a UNIX file system or vice
versa. But going by the common sense argument again, I would personally
want to optimize for NTFS when running on NT, and UNIX filesystems when
runing on UNIX, instead of focusing on corner cases.)
> include them in the installer. This is particularly annoying to catch
> because it isn't obvious that anything is wrong until you run the installer
> and find that those contribs are missing. This has been the case since some
> time after the 1.1.1 release.
There is an easy fix for this, I suppose -- toggle the customary case of
the win32-host from :upper back to :lower.
Can a logical pathname expert weight in on the impact of this change?
It seems to me that :upper stopped being a reasonable choice for DOS and
Windows sometime in the mid-'90s, but maybe there would be side effects
of this change that I am not aware of...