summaryrefslogtreecommitdiff
path: root/README.W32.template
diff options
context:
space:
mode:
Diffstat (limited to 'README.W32.template')
-rw-r--r--README.W32.template241
1 files changed, 241 insertions, 0 deletions
diff --git a/README.W32.template b/README.W32.template
new file mode 100644
index 0000000..2b15584
--- /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.