make-dfsg/README.W32

115 lines
4 KiB
Text
Raw Normal View History

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.