-=head1 BUILDING
-
-=head2 Prerequisites
-
-=over
-
-=item Cygwin b20.1
-
-The latest stable Cygwin suite is beta20.1. It may be
-downloaded from ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/latest/
-or many mirror sites around the world.
-
-=item egcs-1.1.2
-
-This port was built with egcs-1.1.2 downloaded from
-ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/cygwin/egcs-1.1.2/
-
-=item install executable
-
-To make life easier, you should download
-ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/porters/Humblet_Pierre_A/install-cygwin-b20.sh,
-and use it as your install "executable." Just follow the instructions
-that are embedded as comments in the .sh file.
-
-=item Windows NT notes
-
-You should execute a 'chmod -R +w *' on the entire perl source directory.
-The configuration process creates new files (and thus needs write access
-to the directory) and sometimes, especially if you make repeated builds
-in the same directory, overwrites old files. If you do not enable write
-access, you're just asking for trouble. Reminder for B20.1: unless 'ntea'
-is included in the CYGWIN environment variable settings, chmod has no
-effect. See "environment," below.
-
-It is best if you build, test, and install as a normal user, not as
-Administrator or as any member of the Administrators group. There is
-a well-known NT-ism that affects Cygwin: all files that are created
-by any member of the Administrators B<group> are B<NOT> owned by
-that member. The ownership of those files is assigned to the
-Administrators group, instead. If the default access mode for new files
-is -rw-r--r--, then the original creator of the file cannot overwrite
-it: he no longer owns the file, no B<user> does. It is owned by the
-group, but group members don't have write access to it. This causes
-any number of problems, including make test / perl harness failures,
-installation failures, etc.
-
-In some cases, however, it is necessary to install as Administrator. For
-instance, if normal users are not allowed write access to the install
-directory. My solution, in this case, was to transfer ownership of the
-install directory tree (/usr/local) to a single, normal user, and
-set permissions to -rw-r--r-- (drwxr-xr-x for directories, of course).
-If you read the preceeding paragraph carefully, you might suspect that
-changing the permissions on the entire tree to -rw-rw-r--, but allowing
-the Administrators group to keep ownership should solve the problem.
-However, newly created directories (and the perl install creates a lot
-of them) will not allow group write access. Setting umask will not
-fix this problem, because umask is a B<negation> operator; it only
-specifies the types of accesses that will NOT be allowed on new files.
-For instance, umask u=rwx,g=rwx,o=rx means that world ('B<o>thers') will
-never be allowed write access, but owner ('B<u>ser') and B<g>roup B<might>
-be allowed write access. Everybody (u, g, and o) B<might>be allowed
-read access.
-
-In any case, Corinna Vinschen's ntsec patches B<may> eventually
-alleviate this whole mess, and are included in the development
-snapshots as of 24 May 1999. You will need to include 'ntsec' as
-one of the items in the CYGWIN variable setting. However, initial
-tests indicate some incompatibility the 0524 snapshot and this perl
-build.
-
-=item environment
-
-I (csw) found the following steps necessary for a successful build:
-
-=over
-
-=item path
-
-I set my path so that none of the windows directories showed up -
-otherwise Configure found the wrong executables (find, grep, etc).
-It is, however, important that '.' be in the path, because otherwise
-the build process can't execute the ld2 script that is created.
-
-=item mounts
-
-I had to unmount my f: drive. I have cygwin installed under
-F:\cygnus\cygwin-b20\, which is mounted as \. I also ordinarily
-have F:\ mounted as /f (i.e. mounted onto the empty directory
-F:\cygnus\cygwin-b20\f\ ). However, this causes Configure to
-"locate" the awk, tr, sed, etc. programs at
-/f/cygnus/cygwin-b20/usr/bin instead of /usr/bin.
-This ended up causing problems.
-
-I built and tested perl using all binary mounts. However, Eric Fifer
-has built and tested it using text mounts, but reported more failures
-during make test and perl harness. Based on his findings, and experiments
-performed by Sebastien Barre with the static build of perl, I can
-report that these test failures are B<not> due to any differences in
-the perl executable. Most of the failures encountered during a make test
-on text mounts can be eliminated by remounting as binary, and re-running
-the tests using the same executable. These test failures are due to
-problems in the test scripts, not the executable. See Appendix.
-
-One observation from experience with the static build of perl is that
-it's a bad idea to a mix a perl executable that was compiled using binary
-mounts with modules compiled using text mounts, and vice versa. Make
-sure your mount environment matches. This observation has not been
-confirmed with respect to the dynamically linked build of perl.
-
-=item environment variables
-
-For NT users, the CYGWIN variable should include the 'ntea' setting.
-However, if you have FAT drives on your system, as opposed to NTFS,
-please read the Cygwin FAQ concerning ntea before including it in
-your system settings. If you do not use ntea, you will encounter a
-few extra make test and/or perl harness failures. These are not
-indicative of a faulty perl executable, but only that your system
-settings do not allow the types of file access and ownership checking
-that the test scripts are attempting to verify. See Appendix.
-
-I unset INCLUDE and LIB (these two variables are set by MSVC5, and
-inherited from my Windows environment by cygwin). I'm not sure this made
-a difference, but it has caused problems in the past...