From 96cf67bd29957cfde6c5f15cfec7e370c6dbabe2 Mon Sep 17 00:00:00 2001 From: Paul Smith Date: Fri, 17 May 2013 02:29:46 -0400 Subject: Update source file format: remove TABs, use GNU coding styles. --- README.W32.template | 296 ++++++++++++++++++++++++++-------------------------- 1 file changed, 148 insertions(+), 148 deletions(-) (limited to 'README.W32.template') diff --git a/README.W32.template b/README.W32.template index 46954bf..3752c14 100644 --- a/README.W32.template +++ b/README.W32.template @@ -55,7 +55,7 @@ Building with (MinGW-)GCC using build_w32.bat 2. Open a W32 command prompt for your installed (MinGW-)GCC, setup a correct PATH and other environment variables for it, then execute ... - build_w32.bat gcc + build_w32.bat gcc This produces gnumake.exe in the current directory. @@ -75,13 +75,13 @@ Building with (MSVC++-)cl using build_w32.bat or NMakefile e.g. "%VS71COMNTOOLS%vsvars32.bat"; or using a corresponding start menue entry from the cl-installation), then execute EITHER ... - build_w32.bat + build_w32.bat (this produces WinDebug/gnumake.exe and WinRel/gnumake.exe) ... OR ... - nmake /f NMakefile + nmake /f NMakefile (this produces WinDebug/make.exe and WinRel/make.exe). @@ -97,200 +97,200 @@ Building with (MSVC++-)cl using build_w32.bat or NMakefile 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 2000, Windows XP, - 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 Windows compiler. Two compilers supported - officially are the MinGW port of GNU GCC, and the various - versions of the Microsoft C compiler. + This version of make is ported natively to Windows32 platforms + (Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP, + 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 Windows compiler. Two compilers supported + officially are the MinGW port of GNU GCC, and the various + versions of the Microsoft C compiler. - 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. + 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 if 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). + This port prefers if 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://www.cygwin.com/). - Other possibilities are the MKS version of sh.exe, or building + 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://www.cygwin.com/). + Other possibilities are the MKS version of sh.exe, or building your own with a package like NutCracker (DataFocus) or Portage (Consensys). Also MinGW includes sh (http://mingw.org/). GNU make and brain-dead shells (BATCH_MODE_ONLY_SHELL): - Some versions of Bourne shell do 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. In this mode you must have a - working sh.exe in order to use parallel builds (-j). - - 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%). However, parallel - builds ARE supported with Windows shells (cmd.exe and - command.com). See the next section about some peculiarities - of parallel builds on Windows. + Some versions of Bourne shell do 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. In this mode you must have a + working sh.exe in order to use parallel builds (-j). + + 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%). However, parallel + builds ARE supported with Windows shells (cmd.exe and + command.com). See the next section about some peculiarities + of parallel builds on Windows. Support for parallel builds - Parallel builds (-jN) are supported in this port, with 1 - limitation: The number of concurrent processes has a hard - limit of 64, due to the way this port implements waiting for - its subprocesses. + Parallel builds (-jN) are supported in this port, with 1 + limitation: The number of concurrent processes has a hard + limit of 64, due to the way this port implements waiting for + its subprocesses. 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. + 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. + 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, providing the path - is not within quotes, e.g. "x:/test/test.c". - - 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. + 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, providing the path + is not within quotes, e.g. "x:/test/test.c". + + 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. + 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. 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 valid on 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: + Unlike Unix, Windows 95/NT systems encourage pathnames which + contain white space (e.g. C:\Program Files\). These sorts of + pathnames are valid on 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. i.e. "x:/long~1/", which is actually - "x:\longpathtest". Type "dir /x" to view these filenames - within the cmd.exe shell. - 2. Rename the directory so it does not contain white space. + 1. Use 8.3 notation. i.e. "x:/long~1/", which is actually + "x:\longpathtest". Type "dir /x" to view these filenames + within the cmd.exe shell. + 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. + 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"). + 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. + 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: + 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/Target: + touch $@ - SUBDIR/DepTarget: SubDir/TARGET - cp $^ $@ + 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. + 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. + 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. + 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. + 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. + 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. + Please submit bugs via the normal bug reporting mechanism which + is described in the GNU make manual and the base README. ------------------------------------------------------------------------------- Copyright (C) 1996-2013 Free Software Foundation, Inc. -- cgit v1.2.3