-Port of GNU make to Windows NT and Windows 95 \r
-Builds natively with MSVC 2.x or MSVC 4.x compilers.\r
-\r
-To build with nmake on Windows NT or Windows 95:\r
-\r
- 1. Make sure cl.exe is in your %Path%. Example:\r
- \r
- set Path=%Path%;c:/msdev/bin\r
-\r
- 2. Make sure %include% is set to msvc include directory. Example:\r
-\r
- set include=c:/msdev/include\r
-\r
- 3. Make sure %lib% is set to msvc lib directory. Example:\r
-\r
- set lib=c:/msdev/lib\r
-\r
- 4. nmake /f NMakefile\r
-\r
-\r
-There is a bat file (build_w32.bat) for folks who have fear of nmake.\r
- \r
-Outputs:\r
-\r
- WinDebug/make.exe\r
- WinRel/make.exe\r
-\r
-Notes:\r
-\r
- This port prefers you have a working sh.exe somewhere on your\r
- system. If you don't have sh.exe, port falls back to\r
- MSDOS mode for launching programs (via a batch file).\r
- The MSDOS mode style execution has not been tested too\r
- carefully though (I use GNU bash as sh.exe).\r
-\r
- I verified all functionality with a slightly modified version\r
- of make-test-0.4.5 (modifications to get test suite to run\r
- on Windows NT). All tests pass in an environment that includes\r
- sh.exe. \r
-\r
- I did not provide a Visual C project file with this port as\r
- the project file would not be considered freely distributable\r
- (or so I think). It is easy enough to create one though if\r
- you know how to use Visual C. \r
-\r
- I build the program statically to avoid problems locating DLL's\r
- on machines that may not have MSVC runtime installed. If you\r
- prefer, you can change make to build with shared libraries by\r
- changing /MT to /MD in the NMakefile (or build_w32.bat). \r
+Port of GNU make to Windows NT and Windows 95
+Builds natively with MSVC 2.x or MSVC 4.x compilers.
+
+To build with nmake on Windows NT or Windows 95:
+
+ 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
+
+
+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 and sh.exe:
+
+ This port prefers you have a working sh.exe somewhere on your
+ system. If you don't have sh.exe, port falls back to
+ MSDOS mode for launching programs (via a batch file).
+ The MSDOS mode style execution has not been tested too
+ carefully though (I use 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 gnu-win32
+ porting effort. Other possibilites are to get the MKS version
+ of sh.exe or to build your own with a package like
+ NutCracker (DataFocus) or Portage (Consensys).
+
+ Tivoli uses a homegrown port of GNU bash which is not (yet)
+ freely available. It may be available someday, but I am not in control
+ of this decision nor do I influence it. Sorry!
+
+GNU make test suite:
+
+ I verified all functionality with a slightly modified version
+ of make-test-0.4.5 (modifications to get test suite to run
+ on Windows NT). All tests pass in an environment that includes
+ sh.exe. Tested on both Windows NT and Windows 95.
+
+Building GNU make on Windows NT and Windows 95 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 build_w32.bat).
+
+ Program has not been built under non-Intel architectures (yet).
+
+ I have not tried to build with any other compilers than MSVC.
+
+Pathnames and white space:
+
+ Unlike Unix, WIN32 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.
+
+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.
+
+Bug reports:
+
+ Please submit bugs via the normal bug reporting mechanism
+ which is described in one of the texinfo files. If you don't
+ have texinfo for Windows NT or Windows 95, these files are simple
+ text files and can be read with a text editor.
+
-Port of GNU make to Windows NT and Windows 95 \r
-Builds natively with MSVC 2.x or MSVC 4.x compilers.\r
-\r
-To build with nmake on Windows NT or Windows 95:\r
-\r
- 1. Make sure cl.exe is in your %Path%. Example:\r
- \r
- set Path=%Path%;c:/msdev/bin\r
-\r
- 2. Make sure %include% is set to msvc include directory. Example:\r
-\r
- set include=c:/msdev/include\r
-\r
- 3. Make sure %lib% is set to msvc lib directory. Example:\r
-\r
- set lib=c:/msdev/lib\r
-\r
- 4. nmake /f NMakefile\r
-\r
-\r
-There is a bat file (build_w32.bat) for folks who have fear of nmake.\r
- \r
-Outputs:\r
-\r
- WinDebug/make.exe\r
- WinRel/make.exe\r
-\r
-Notes:\r
-\r
- This port prefers you have a working sh.exe somewhere on your\r
- system. If you don't have sh.exe, port falls back to\r
- MSDOS mode for launching programs (via a batch file).\r
- The MSDOS mode style execution has not been tested too\r
- carefully though (I use GNU bash as sh.exe).\r
-\r
- I verified all functionality with a slightly modified version\r
- of make-test-0.4.5 (modifications to get test suite to run\r
- on Windows NT). All tests pass in an environment that includes\r
- sh.exe. \r
-\r
- I did not provide a Visual C project file with this port as\r
- the project file would not be considered freely distributable\r
- (or so I think). It is easy enough to create one though if\r
- you know how to use Visual C. \r
-\r
- I build the program statically to avoid problems locating DLL's\r
- on machines that may not have MSVC runtime installed. If you\r
- prefer, you can change make to build with shared libraries by\r
- changing /MT to /MD in the NMakefile (or build_w32.bat). \r
+Port of GNU make to Windows NT and Windows 95
+Builds natively with MSVC 2.x or MSVC 4.x compilers.
+
+To build with nmake on Windows NT or Windows 95:
+
+ 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
+
+
+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 and sh.exe:
+
+ This port prefers you have a working sh.exe somewhere on your
+ system. If you don't have sh.exe, port falls back to
+ MSDOS mode for launching programs (via a batch file).
+ The MSDOS mode style execution has not been tested too
+ carefully though (I use 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 gnu-win32
+ porting effort. Other possibilites are to get the MKS version
+ of sh.exe or to build your own with a package like
+ NutCracker (DataFocus) or Portage (Consensys).
+
+ Tivoli uses a homegrown port of GNU bash which is not (yet)
+ freely available. It may be available someday, but I am not in control
+ of this decision nor do I influence it. Sorry!
+
+GNU make test suite:
+
+ I verified all functionality with a slightly modified version
+ of make-test-0.4.5 (modifications to get test suite to run
+ on Windows NT). All tests pass in an environment that includes
+ sh.exe. Tested on both Windows NT and Windows 95.
+
+Building GNU make on Windows NT and Windows 95 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 build_w32.bat).
+
+ Program has not been built under non-Intel architectures (yet).
+
+ I have not tried to build with any other compilers than MSVC.
+
+Pathnames and white space:
+
+ Unlike Unix, WIN32 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.
+
+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.
+
+Bug reports:
+
+ Please submit bugs via the normal bug reporting mechanism
+ which is described in one of the texinfo files. If you don't
+ have texinfo for Windows NT or Windows 95, these files are simple
+ text files and can be read with a text editor.
+
projects / platform / upstream / make.git / commitdiff