From 185f7c587b2e4d9195064cbfc562505822cf4d82 Mon Sep 17 00:00:00 2001 From: Paul Smith Date: Tue, 31 Aug 1999 17:02:31 +0000 Subject: * Large file support for AIX, HP-UX, and IRIX. * W32 support for Cygnus Cygwin shell (bash). --- README.W32.template | 241 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 README.W32.template (limited to 'README.W32.template') diff --git a/README.W32.template b/README.W32.template new file mode 100644 index 00000000..2b15584f --- /dev/null +++ b/README.W32.template @@ -0,0 +1,241 @@ +Port of GNU make to Windows NT and Windows 95 +Builds natively with MSVC 2.x or MSVC 4.x compilers. +Should also build fine with MSVC 5.x and 6.x (though not confirmed). + +This Windows 32-bit port of GNU make is maintained primarily by Rob +Tulloh, who is also the author of this README. + +To build with nmake on Windows NT, Windows 95, or Windows 98: + + 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 + + + A short cut to steps 1, 2, and 3 is to run VCVARS32.bat before + invoking namke. For example: + + c: + cd \msdev\bin + VCVARS32.bat + cd \path\to\make-%VERSION% + 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 on Windows 32-bit platforms: + + This version of make is ported natively to Windows32 platforms + (Windows NT 3.51, Windows NT 4.0, Windows 95, and Windows 98). It + does not rely on any 3rd party software or add-on packages for + building. The only thing needed is a version of Visual C++, + which is the predominant compiler used on Windows32 platforms. + + Do not confuse this port of GNU make with other Windows32 projects + which provide a GNU make binary. These are separate projects + and are not connected to this port effort. + +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, the port falls back to + MSDOS mode for launching programs (via a batch file). + The MSDOS mode style execution has not been tested that + carefully though (The author uses 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 "Cygwin" + porting effort (http://sourceware.cygnus.com/cygwin). + Other possibilities are the MKS version of sh.exe, or building + your own with a package like NutCracker (DataFocus) or Portage + (Consensys). + +GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL): + + Some versions of Bourne shell does not behave well when invoked + as 'sh -c' from CreateProcess(). The main problem is they seem + to have a hard time handling quoted strings correctly. This can + be circumvented by writing commands to be executed to a batch + file and then executing the command by calling 'sh file'. + + To work around this difficulty, this version of make supports + a 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 Windows32 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%). + +GNU make and Cygnus GNU Windows32 tools: + + Good news! Make now has native support for Cygwin sh. To enable, + define the HAVE_CYGWIN_SHELL in config.h and rebuild make + from scratch. This version of make tested with B20.1 of Cygwin. + Do not define BATCH_MODE_ONLY_SHELL if you use HAVE_CYGWIN_SHELL. + +GNU make and the 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 + + 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-%VERSION% (modifications to get test suite to run + on Windows NT). All tests pass in an environment that includes + sh.exe. Tests were performed on both Windows NT and Windows 95. + +Building GNU make on Windows NT and Windows 95/98 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 in build_w32.bat). + + The program has not been built for non-Intel architectures (yet). + + I have not tried to build with any other compilers than MSVC. I + have heard that this is possible though so don't be afraid to + notify me of your successes! + +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. + +FAT: + + Version 3.76 added support for FAT filesystems. Make + works around some difficulties with stat'ing of + files and caching of filenames and directories internally. + +Bug reports: + + Please submit bugs via the normal bug reporting mechanism which + is described in the GNU make manual and the base README. -- cgit v1.2.1