1 Port of GNU Make to 32-bit protected mode on MSDOS and MS-Windows.
3 Builds with DJGPP v2 port of GNU C/C++ compiler and utilities.
6 New (since 3.74) DOS-specific features:
8 1. Supports long filenames when run from DOS box on Windows 9x.
10 2. Supports both stock DOS COMMAND.COM and Unix-style shells
11 (details in 'Notes' below).
13 3. Supports DOS drive letters in dependencies and pattern rules.
15 4. Better support for DOS-style backslashes in pathnames (but see
18 5. The $(shell) built-in can run arbitrary complex commands,
19 including pipes and redirection, even when COMMAND.COM is your
22 6. Can be built without floating-point code (see below).
24 7. Supports signals in child programs and restores the original
25 directory if the child was interrupted.
27 8. Can be built without (a previous version of) Make.
29 9. The build process requires only standard tools. (Optional
30 targets like "check:" still need additional programs, though,
33 10. Beginning with v3.78, the test suite works in the DJGPP
34 environment (requires Perl and auxiliary tools; see below).
37 To install a binary distribution:
39 Simply unzip the makNNNb.zip file (where NNN is the version number)
40 preserving the directory structure (-d switch if you use PKUNZIP).
41 If you are installing Make on Windows 9X or Windows 2000, use an
42 unzip program that supports long filenames in zip files. After
43 unzipping, make sure the directory with make.exe is on your PATH,
44 and that's all you need to use Make.
47 To build from sources:
49 1. Unzip the archive, preserving the directory structure (-d switch
50 if you use PKUNZIP). If you build Make on Windows 9X or Windows
51 2000, use an unzip program that supports long filenames in zip
54 If you are unpacking an official GNU source distribution, use
55 either DJTAR (which is part of the DJGPP development
56 environment), or the DJGPP port of GNU Tar.
58 2. If you have a working Make already, you can run:
62 3. If you don't have a working Make already you can bootstrap one
67 4. If you are building from outside of the source directory, you
68 need to tell Make where the sources are, like this:
70 make -f c:/djgpp/gnu/make/Basic.mk SRCDIR=c:/djgpp/gnu/make
74 c:/djgpp/gnu/make/builddos.bat c:/djgpp/gnu/make
76 5. To run the test suite, type "make check". This requires a Unix
77 shell (I used the DJGPP port of Bash 2.03), Perl, Sed, Fileutils
80 6. To install copy make.exe to the preferred location.
82 Since GNU make 4.3, support for customized platform installations
83 has been removed. If you'd like to collaborate on reinstating
84 these capabilities, contact bug-make@gnu.org.
92 This is probably the most significant improvement, first
93 introduced in the port of GNU Make 3.75.
95 The original behavior of GNU Make is to invoke commands
96 directly, as long as they don't include characters special to
97 the shell or internal shell commands, because that is faster.
98 When shell features like redirection or filename wildcards are
99 involved, Make calls the shell.
101 This port supports both DOS shells (the stock COMMAND.COM and its
102 4DOS/NDOS replacements), and Unix-style shells (tested with the
103 venerable Stewartson's 'ms_sh' 2.3 and the DJGPP port of 'bash' by
104 Daisuke Aoyama <jack@st.rim.or.jp>).
106 When the $SHELL variable points to a Unix-style shell, Make
107 works just like you'd expect on Unix, calling the shell for any
108 command that involves characters special to the shell or
109 internal shell commands. The only difference is that, since
110 there is no standard way to pass command lines longer than the
111 infamous DOS 126-character limit, this port of Make writes the
112 command line to a temporary disk file and then invokes the shell
115 If $SHELL points to a DOS-style shell, however, Make will not
116 call it automatically, as it does with Unix shells. Stock
117 COMMAND.COM is too dumb and would unnecessarily limit the
118 functionality of Make. For example, you would not be able to
119 use long command lines in commands that use redirection or
120 pipes. Therefore, when presented with a DOS shell, this port of
121 Make will emulate most of the shell functionality, like
122 redirection and pipes, and shall only call the shell when a
123 batch file or a command internal to the shell is invoked. (Even
124 when a command is an internal shell command, Make will first
125 search the $PATH for it, so that if a Makefile calls 'mkdir',
126 you can install, say, a port of GNU 'mkdir' and have it called
129 The key to all this is the extended functionality of 'spawn' and
130 'system' functions from the DJGPP library; this port just calls
131 'system' where it would invoke the shell on Unix. The most
132 important aspect of these functions is that they use a special
133 mechanism to pass long (up to 16KB) command lines to DJGPP
134 programs. In addition, 'system' emulates some internal
135 commands, like 'cd' (so that you can now use forward slashes
136 with it, and can also change the drive if the directory is on
137 another drive). Another aspect worth mentioning is that you can
138 call Unix shell scripts directly, provided that the shell whose
139 name is mentioned on the first line of the script is installed
140 anywhere along the $PATH. It is impossible to tell here
141 everything about these functions; refer to the DJGPP library
142 reference for more details.
144 The $(shell) built-in is implemented in this port by calling
145 'popen'. Since 'popen' calls 'system', the above considerations
146 are valid for $(shell) as well. In particular, you can put
147 arbitrary complex commands, including pipes and redirection,
148 inside $(shell), which is in many cases a valid substitute for
149 the Unix-style command substitution (`command`) feature.
152 2. "SHELL=/bin/sh" -- or is it?
154 Many Unix Makefiles include a line which sets the SHELL, for
155 those versions of Make which don't have this as the default.
156 Since many DOS systems don't have 'sh' installed (in fact, most
157 of them don't even have a '/bin' directory), this port takes
158 such directives with a grain of salt. It will only honor such a
159 directive if the basename of the shell name (like 'sh' in the
160 above example) can indeed be found in the directory that is
161 mentioned in the SHELL= line ('/bin' in the above example), or
162 in the current working directory, or anywhere on the $PATH (in
163 that order). If the basename doesn't include a filename
164 extension, Make will look for any known extension that indicates
165 an executable file (.exe, .com, .bat, .btm, .sh, and even .sed
166 and .pl). If any such file is found, then $SHELL will be
167 defined to the exact pathname of that file, and that shell will
168 hence be used for the rest of processing. But if the named
169 shell is *not* found, the line which sets it will be effectively
170 ignored, leaving the value of $SHELL as it was before. Since a
171 lot of decisions that this port makes depend on the gender of
172 the shell, I feel it doesn't make any sense to tailor Make's
173 behavior to a shell which is nowhere to be found.
175 Note that the above special handling of "SHELL=" only happens
176 for Makefiles; if you set $SHELL in the environment or on the
177 Make command line, you are expected to give the complete
178 pathname of the shell, including the filename extension.
180 The default value of $SHELL is computed as on Unix (see the Make
181 manual for details), except that if $SHELL is not defined in the
182 environment, $COMSPEC is used. Also, if an environment variable
183 named $MAKESHELL is defined, it takes precedence over both
184 $COMSPEC and $SHELL. Note that, unlike Unix, $SHELL in the
185 environment *is* used to set the shell (since on MSDOS, it's
186 unlikely that the interactive shell will not be suitable for
187 Makefile processing).
189 The bottom line is that you can now write Makefiles where some
190 of the targets require a real (i.e. Unix-like) shell, which will
191 nevertheless work when such shell is not available (provided, of
192 course, that the commands which should always work, don't
193 require such a shell). More important, you can convert Unix
194 Makefiles to MSDOS and leave the line which sets the shell
195 intact, so that people who do have Unixy shell could use it for
196 targets which aren't converted to DOS (like 'install' and
197 'uninstall', for example).
200 3. Default directories.
202 GNU Make knows about standard directories where it searches for
203 library and include files mentioned in the Makefile. Since
204 MSDOS machines don't have standard places for these, this port
205 will search ${DJDIR}/lib and ${DJDIR}/include respectively.
206 $DJDIR is defined automatically by the DJGPP startup code as the
207 root of the DJGPP installation tree (unless you've tampered with
208 the DJGPP.ENV file). This should provide reasonable default
209 values, unless you moved parts of DJGPP to other directories.
212 4. Letter-case in filenames.
214 If you run Make on Windows 9x, you should be aware of the
215 letter-case issue. Make is internally case-sensitive, but all
216 file operations are case-insensitive on Windows 9x, so
217 e.g. files 'FAQ', 'faq' and 'Faq' all refer to the same file, as
218 far as Windows is concerned. The underlying DJGPP C library
219 functions honor the letter-case of the filenames they get from
220 the OS, except that by default, they down-case 8+3 DOS filenames
221 which are stored in upper case in the directory and would break
222 many Makefiles otherwise. (The details of which filenames are
223 converted to lower case are explained in the DJGPP libc docs,
224 under the '_preserve_fncase' and '_lfn_gen_short_fname'
225 functions, but as a thumb rule, any filename that is stored in
226 upper case in the directory, is a valid DOS 8+3 filename and
227 doesn't include characters invalid on MSDOS FAT filesystems,
228 will be automatically down-cased.) User reports that I have
229 indicate that this default behavior is generally what you'd
230 expect; however, your input is most welcome.
232 In any case, if you hit a situation where you must force Make to
233 get the 8+3 DOS filenames in upper case, set FNCASE=y in the
234 environment or in the Makefile.
237 5. DOS-style pathnames.
239 There are a lot of places throughout the program sources which
240 make implicit assumptions about the pathname syntax. In
241 particular, the directories are assumed to be separated by '/',
242 and any pathname which doesn't begin with a '/' is assumed to be
243 relative to the current directory. This port attempts to
244 support DOS-style pathnames which might include the drive letter
245 and use backslashes instead of forward slashes. However, this
246 support is not complete; I feel that pursuing this support too
247 far might break some more important features, particularly if
248 you use a Unix-style shell (where a backslash is a quote
249 character). I only consider support of backslashes desirable
250 because some Makefiles invoke non-DJGPP programs which don't
251 understand forward slashes. A notable example of such programs
252 is the standard programs which come with MSDOS. Otherwise, you
253 are advised to stay away from backslashes whenever possible. In
254 particular, filename globbing won't work on pathnames with
255 backslashes, because the GNU 'glob' library doesn't support them
256 (backslash is special in filename wildcards, and I didn't want
259 One feature which *does* work with backslashes is the filename-
260 related built-in functions such as $(dir), $(notdir), etc.
261 Drive letters in pathnames are also fully supported.
268 Bugs that are clearly related to the MSDOS/DJGPP port should be
269 reported first on the comp.os.msdos.djgpp news group (if you cannot
270 post to Usenet groups, write to the DJGPP mailing list,
271 <djgpp@delorie.com>, which is an email gateway into the above news
272 group). For other bugs, please follow the procedure explained in
273 the "Bugs" chapter of the Info docs. If you don't have an Info
274 reader, look up that chapter in the 'make.i1' file with any text
279 Eli Zaretskii <eliz@is.elta.co.il>
282 -------------------------------------------------------------------------------
283 Copyright (C) 1996-2020 Free Software Foundation, Inc.
284 This file is part of GNU Make.
286 GNU Make is free software; you can redistribute it and/or modify it under the
287 terms of the GNU General Public License as published by the Free Software
288 Foundation; either version 3 of the License, or (at your option) any later
291 GNU Make is distributed in the hope that it will be useful, but WITHOUT ANY
292 WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
293 A PARTICULAR PURPOSE. See the GNU General Public License for more details.
295 You should have received a copy of the GNU General Public License along with
296 this program. If not, see <http://www.gnu.org/licenses/>.