* Large file support for AIX, HP-UX, and IRIX.

* W32 support for Cygnus Cygwin shell (bash).

1 files changed, 0 insertions, 222 deletions

diff --git a/README.W32 b/README.W32
deleted file mode 100644
index ca7f32c6..00000000
--- a/README.W32
+++ /dev/null
@@ -1,222 +0,0 @@
-Port of GNU make to Windows NT and Windows 95
-Builds natively with MSVC 2.x or MSVC 4.x compilers.
-
-To build with nmake on Windows NT or Windows 95:
-
-	1. Make sure cl.exe is in your %Path%. Example:
-
-		set Path=%Path%;c:/msdev/bin
-
-	2. Make sure %include% is set to msvc include directory. Example:
-
-		set include=c:/msdev/include
-
-	3. Make sure %lib% is set to msvc lib directory. Example:
-
-		set lib=c:/msdev/lib
-
-	4. nmake /f NMakefile
-
-
-There is a bat file (build_w32.bat) for folks who have fear of nmake.
-
-Outputs:
-
-	WinDebug/make.exe
-	WinRel/make.exe
-
-
--- Notes/Caveats --
-
-GNU make and sh.exe:
-
-	This port prefers you have a working sh.exe somewhere on your
-	system. If you don't have sh.exe, port falls back to
-	MSDOS mode for launching programs (via a batch file).
-	The MSDOS mode style execution has not been tested too
-	carefully though (I use GNU bash as sh.exe).
-
-	There are very few true ports of Bourne shell for NT right now.
-	There is a version of GNU bash available from Cygnus gnu-win32
-	porting effort.	 Other possibilities are to get the MKS version
-	of sh.exe or to build your own with a package like
-	NutCracker (DataFocus) or Portage (Consensys).
-
-	Tivoli uses a homegrown port of GNU bash which is not (yet)
-	freely available. It may be available someday, but I am not in control
-	of this decision nor do I influence it. Sorry!
-
-GNU make and Cygnus GNU WIN32 tools (BATCH_MODE_ONLY_SHELL)
-
-	GNU make now has support for the Cygnus GNU WIN32 toolset. The
-	GNU WIN32 version of Bourne shell does not behave well when
-	invoked as 'sh -c' from CreateProcess().  The main problem is it
-	seems to have a hard time handling quoted strings correctly. This
-	problem goes away when invoking the Cygnus shell on a shell script.
-
-	To work around this difficulty, this version of make supports
-	a new batch mode.  When BATCH_MODE_ONLY_SHELL is defined at compile
-	time, make forces all command lines to be executed via script
-	files instead of by command line.
-
-	A native WIN32 system with no Bourne shell will also run
-	in batch mode.  All command lines will be put into batch files
-	and executed via $(COMSPEC) (%COMSPEC%).
-
-	If you wish to use Cygnus' GNUWIN32 shell, be sure you define
-	BATCH_MODE_ONLY_SHELL in the config.h.W32 prior to building make.
-	The new feataure was tested with the b18 version of the Cygnus
-	user tools.
-
-GNU make and MKS shell
-
-	There is now semi-official support for the MKS shell. To turn this
-	support on, define HAVE_MKS_SHELL in the config.h.W32 before you
-	build make.  Do not define BATCH_MODE_ONLY_SHELL if you turn
-	on HAVE_MKS_SHELL.
-
-GNU make handling of drive letters in pathnames (PATH, vpath, VPATH):
-
-	There is a caveat that should be noted with respect to handling
-	single character pathnames on Windows systems.	When colon is
-	used in PATH variables, make tries to be smart about knowing when
-	you are using colon as a separator versus colon as a drive
-	letter.	 Unfortunately, something as simple as the string 'x:/'
-	could be interpreted 2 ways: (x and /) or (x:/).
-
-	Make chooses to interpret a letter plus colon (e.g. x:/) as a
-	drive letter pathname.	If it is necessary to use single
-	character directories in paths (VPATH, vpath, Path, PATH), the
-	user must do one of two things:
-
-	 a. Use semicolon as the separator to disambiguate colon. For
-	    example use 'x;/' if you want to say 'x' and '/' are
-	    separate components.
-
-	 b. Qualify the directory name so that there is more than
-	    one character in the path(s) used. For example, none
-	    of these settings are ambiguous:
-
-	      ./x:./y
-	      /some/path/x:/some/path/y
-	      x:/some/path/x:x:/some/path/y
-
-	These caveats affect Windows systems only (Windows NT and
-	Windows 95) and can be ignored for other platforms.
-
-	Please note that you are free to mix colon and semi-colon in the
-	specification of paths.	 Make is able to figure out the intended
-	result and convert the paths internally to the format needed
-	when interacting with the operating system.
-
-	You are encouraged to use colon as the separator character.
-	This should ease the pain of deciding how to handle various path
-	problems which exist between platforms.	 If colon is used on
-	both Unix and Windows systems, then no ifdef'ing will be
-	necessary in the makefile source.
-
-GNU make test suite:
-
-	I verified all functionality with a slightly modified version
-	of make-test-0.4.5 (modifications to get test suite to run
-	on Windows NT). All tests pass in an environment that includes
-	sh.exe. Tested on both Windows NT and Windows 95.
-
-Building GNU make on Windows NT and Windows 95 with Microsoft Visual C
-
-	I did not provide a Visual C project file with this port as
-	the project file would not be considered freely distributable
-	(or so I think). It is easy enough to create one though if
-	you know how to use Visual C.
-
-	I build the program statically to avoid problems locating DLL's
-	on machines that may not have MSVC runtime installed. If you
-	prefer, you can change make to build with shared libraries by
-	changing /MT to /MD in the NMakefile (or build_w32.bat).
-
-	Program has not been built under non-Intel architectures (yet).
-
-	I have not tried to build with any other compilers than MSVC.
-
-Pathnames and white space:
-
-	Unlike Unix, Windows 95/NT systems encourage pathnames which
-	contain white space (e.g. C:\Program Files\). These sorts of pathnames
-	are legal under Unix too, but are never encouraged. There is
-	at least one place in make (VPATH/vpath handling) where paths
-	containing white space will simply not work. There may be others
-	too. I chose to not try and port make in such a way so that
-	these sorts of paths could be handled. I offer these suggestions
-	as workarounds:
-
-		1. Use 8.3 notation
-		2. Rename the directory so it does not contain white space.
-
-	If you are unhappy with this choice, this is free software
-	and you are free to take a crack at making this work. The code
-	in w32/pathstuff.c and vpath.c would be the places to start.
-
-Pathnames and Case insensitivity:
-
-	Unlike Unix, Windows 95/NT systems are case insensitive but case
-	preserving.  For example if you tell the file system to create a
-	file named "Target", it will preserve the case.  Subsequent access to
-	the file with other case permutations will succeed (i.e. opening a
-	file named "target" or "TARGET" will open the file "Target").
-
-	By default, GNU make retains its case sensitivity when comparing
-	target names and existing files or directories.  It can be
-	configured, however, into a case preserving and case insensitive
-	mode by adding a define for HAVE_CASE_INSENSITIVE_FS to
-	config.h.W32.
-
-	For example, the following makefile will create a file named
-	Target in the directory subdir which will subsequently be used
-	to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET.
-	Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link
-	will not be made:
-
-	subdir/Target:
-		touch $@
-
-	SUBDIR/DepTarget: SubDir/TARGET
-		cp $^ $@
-
-	Reliance on this behavior also eliminates the ability of GNU make
-	to use case in comparison of matching rules.  For example, it is
-	not possible to set up a C++ rule using %.C that is different
-	than a C rule using %.c.  GNU make will consider these to be the
-	same rule and will issue a warning.
-
-SAMBA/NTFS/VFAT:
-
-	I have not had any success building the debug version of this
-	package using SAMBA as my file server. The reason seems to be
-	related to the way VC++ 4.0 changes the case name of the pdb
-	filename it is passed on the command line. It seems to change
-	the name always to to lower case. I contend that
-	the VC++ compiler should not change the casename of files that
-	are passed as arguments on the command line. I don't think this
-	was a problem in MSVC 2.x, but I know it is a problem in MSVC 4.x.
-
-	The package builds fine on VFAT and NTFS filesystems.
-
-	Most all of the development I have done to date has been using
-	NTFS and long file names. I have not done any considerable work
-	under VFAT. VFAT users may wish to be aware that this port
-	of make does respect case sensitivity.
-
-	Version 3.76 contains some preliminary support for FAT.	 Make
-	now tries to work around some difficulties with stat'ing of
-	files and caching of filenames and directories internally.
-	There is still a known problem with filenames sometimes being
-	found to have modification dates in the future which cause make
-	to complain about the file and exit (remake.c).
-
-Bug reports:
-
-	Please submit bugs via the normal bug reporting mechanism
-	which is described in one of the Texinfo files. If you don't
-	have Texinfo for Windows NT or Windows 95, these files are simple
-	text files and can be read with a text editor.
-