1 This version of GNU make has been tested on Microsoft Windows 2000/XP/2003.
2 It has also been used on Windows 95/98/NT, and on OS/2.
4 It builds natively with MSVC 2.x, 4.x, 5.x, 6.x, and 2003 as well as
5 .NET 7.x and .NET 2003.
7 It builds with the MinGW port of GCC 3.x (tested with GCC 3.4.2).
9 The Windows 32-bit port of GNU make is maintained jointly by various
10 people. It was originally made by Rob Tulloh.
13 Do this first, regardless of the build method you choose:
14 ---------------------------------------------------------
16 0. If your sources come from CVS, read the Windows-specific section of
19 1. At the Windows command prompt run:
21 if not exist config.h copy config.h.W32 config.h
23 Then edit config.h to your liking (especially the few shell-related
24 defines near the end, or HAVE_CASE_INSENSITIVE_FS which corresponds
25 to './configure --enable-case-insensitive-file-system').
28 Using make_msvc_net2003.vcproj
29 ------------------------------
31 2. Open make_msvc_net2003.vcproj in MSVS71 or MSVC71 or any compatible IDE,
32 then build this project as usual.
35 Building with (MinGW-)GCC using build_w32.bat
36 ---------------------------------------------
38 2. Open a W32 command prompt for your installed (MinGW-)GCC, setup a
39 correct PATH and other environment variables for it, then execute ...
43 This produces gnumake.exe in the current directory.
46 Building with (MSVC++-)cl using build_w32.bat or NMakefile
47 ----------------------------------------------------------
49 2. Open a W32 command prompt for your installed (MSVC++-)cl, setup a
50 correct PATH and other environment variables for it (usually via
51 executing vcvars32.bat or vsvars32.bat from the cl-installation,
52 e.g. "%VS71COMNTOOLS%vsvars32.bat"; or using a corresponding start
53 menue entry from the cl-installation), then execute EITHER ...
57 (this produces WinDebug/gnumake.exe and WinRel/gnumake.exe)
63 (this produces WinDebug/make.exe and WinRel/make.exe).
70 GNU make on Windows 32-bit platforms:
72 This version of make is ported natively to Windows32 platforms
73 (Windows NT 3.51, Windows NT 4.0, Windows 95, and Windows 98). It
74 does not rely on any 3rd party software or add-on packages for
75 building. The only thing needed is a version of Visual C++,
76 which is the predominant compiler used on Windows32 platforms.
78 Do not confuse this port of GNU make with other Windows32 projects
79 which provide a GNU make binary. These are separate projects
80 and are not connected to this port effort.
84 This port prefers you have a working sh.exe somewhere on your
85 system. If you don't have sh.exe, the port falls back to
86 MSDOS mode for launching programs (via a batch file).
87 The MSDOS mode style execution has not been tested that
88 carefully though (The author uses GNU bash as sh.exe).
90 There are very few true ports of Bourne shell for NT right now.
91 There is a version of GNU bash available from Cygnus "Cygwin"
92 porting effort (http://www.cygwin.com/).
93 Other possibilities are the MKS version of sh.exe, or building
94 your own with a package like NutCracker (DataFocus) or Portage
95 (Consensys). Also MinGW includes sh (http://mingw.org/).
97 GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL):
99 Some versions of Bourne shell do not behave well when invoked
100 as 'sh -c' from CreateProcess(). The main problem is they seem
101 to have a hard time handling quoted strings correctly. This can
102 be circumvented by writing commands to be executed to a batch
103 file and then executing the command by calling 'sh file'.
105 To work around this difficulty, this version of make supports
106 a batch mode. When BATCH_MODE_ONLY_SHELL is defined at compile
107 time, make forces all command lines to be executed via script
108 files instead of by command line. In this mode you must have a
109 working sh.exe in order to use parallel builds (-j).
111 A native Windows32 system with no Bourne shell will also run
112 in batch mode. All command lines will be put into batch files
113 and executed via $(COMSPEC) (%COMSPEC%). Note that parallel
114 builds (-j) require a working Bourne shell; they will not work
117 GNU make and Cygnus GNU Windows32 tools:
119 Good news! Make now has native support for Cygwin sh. To enable,
120 define the HAVE_CYGWIN_SHELL in config.h and rebuild make
121 from scratch. This version of make tested with B20.1 of Cygwin.
122 Do not define BATCH_MODE_ONLY_SHELL if you use HAVE_CYGWIN_SHELL.
124 GNU make and the MKS shell:
126 There is now semi-official support for the MKS shell. To turn this
127 support on, define HAVE_MKS_SHELL in the config.h.W32 before you
128 build make. Do not define BATCH_MODE_ONLY_SHELL if you turn
131 GNU make handling of drive letters in pathnames (PATH, vpath, VPATH):
133 There is a caveat that should be noted with respect to handling
134 single character pathnames on Windows systems. When colon is
135 used in PATH variables, make tries to be smart about knowing when
136 you are using colon as a separator versus colon as a drive
137 letter. Unfortunately, something as simple as the string 'x:/'
138 could be interpreted 2 ways: (x and /) or (x:/).
140 Make chooses to interpret a letter plus colon (e.g. x:/) as a
141 drive letter pathname. If it is necessary to use single
142 character directories in paths (VPATH, vpath, Path, PATH), the
143 user must do one of two things:
145 a. Use semicolon as the separator to disambiguate colon. For
146 example use 'x;/' if you want to say 'x' and '/' are
149 b. Qualify the directory name so that there is more than
150 one character in the path(s) used. For example, none
151 of these settings are ambiguous:
154 /some/path/x:/some/path/y
155 x:/some/path/x:x:/some/path/y
157 Please note that you are free to mix colon and semi-colon in the
158 specification of paths. Make is able to figure out the intended
159 result and convert the paths internally to the format needed
160 when interacting with the operating system, providing the path
161 is not within quotes, e.g. "x:/test/test.c".
163 You are encouraged to use colon as the separator character.
164 This should ease the pain of deciding how to handle various path
165 problems which exist between platforms. If colon is used on
166 both Unix and Windows systems, then no ifdef'ing will be
167 necessary in the makefile source.
171 I verified all functionality with a slightly modified version
172 of make-test-%VERSION% (modifications to get test suite to run
173 on Windows NT). All tests pass in an environment that includes
174 sh.exe. Tests were performed on both Windows NT and Windows 95.
176 Building GNU make on Windows NT and Windows 95/98 with Microsoft Visual C:
178 I did not provide a Visual C project file with this port as
179 the project file would not be considered freely distributable
180 (or so I think). It is easy enough to create one, though, if
181 you know how to use Visual C.
183 I build the program statically to avoid problems locating DLL's
184 on machines that may not have MSVC runtime installed. If you
185 prefer, you can change make to build with shared libraries by
186 changing /MT to /MD in the NMakefile (or in build_w32.bat).
188 The program has not been built for non-Intel architectures (yet).
190 I have not tried to build with any other compilers than MSVC. I
191 have heard that this is possible though so don't be afraid to
192 notify me of your successes!
194 Pathnames and white space:
196 Unlike Unix, Windows 95/NT systems encourage pathnames which
197 contain white space (e.g. C:\Program Files\). These sorts of
198 pathnames are legal under Unix too, but are never encouraged.
199 There is at least one place in make (VPATH/vpath handling) where
200 paths containing white space will simply not work. There may be
201 others too. I chose to not try and port make in such a way so
202 that these sorts of paths could be handled. I offer these
203 suggestions as workarounds:
205 1. Use 8.3 notation. i.e. "x:/long~1/", which is actually
206 "x:\longpathtest". Type "dir /x" to view these filenames
207 within the cmd.exe shell.
208 2. Rename the directory so it does not contain white space.
210 If you are unhappy with this choice, this is free software
211 and you are free to take a crack at making this work. The code
212 in w32/pathstuff.c and vpath.c would be the places to start.
214 Pathnames and Case insensitivity:
216 Unlike Unix, Windows 95/NT systems are case insensitive but case
217 preserving. For example if you tell the file system to create a
218 file named "Target", it will preserve the case. Subsequent access to
219 the file with other case permutations will succeed (i.e. opening a
220 file named "target" or "TARGET" will open the file "Target").
222 By default, GNU make retains its case sensitivity when comparing
223 target names and existing files or directories. It can be
224 configured, however, into a case preserving and case insensitive
225 mode by adding a define for HAVE_CASE_INSENSITIVE_FS to
228 For example, the following makefile will create a file named
229 Target in the directory subdir which will subsequently be used
230 to satisfy the dependency of SUBDIR/DepTarget on SubDir/TARGET.
231 Without HAVE_CASE_INSENSITIVE_FS configured, the dependency link
237 SUBDIR/DepTarget: SubDir/TARGET
240 Reliance on this behavior also eliminates the ability of GNU make
241 to use case in comparison of matching rules. For example, it is
242 not possible to set up a C++ rule using %.C that is different
243 than a C rule using %.c. GNU make will consider these to be the
244 same rule and will issue a warning.
248 I have not had any success building the debug version of this
249 package using SAMBA as my file server. The reason seems to be
250 related to the way VC++ 4.0 changes the case name of the pdb
251 filename it is passed on the command line. It seems to change
252 the name always to to lower case. I contend that the VC++
253 compiler should not change the casename of files that are passed
254 as arguments on the command line. I don't think this was a
255 problem in MSVC 2.x, but I know it is a problem in MSVC 4.x.
257 The package builds fine on VFAT and NTFS filesystems.
259 Most all of the development I have done to date has been using
260 NTFS and long file names. I have not done any considerable work
261 under VFAT. VFAT users may wish to be aware that this port of
262 make does respect case sensitivity.
266 Version 3.76 added support for FAT filesystems. Make works
267 around some difficulties with stat'ing of files and caching of
268 filenames and directories internally.
272 Please submit bugs via the normal bug reporting mechanism which
273 is described in the GNU make manual and the base README.