diff options
Diffstat (limited to 'README.W32')
| -rw-r--r-- | README.W32 | 222 |
1 files changed, 0 insertions, 222 deletions
diff --git a/README.W32 b/README.W32 deleted file mode 100644 index ca7f32c..0000000 --- a/README.W32 +++ /dev/null @@ -1,222 +0,0 @@ -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 possibilities 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 and Cygnus GNU WIN32 tools (BATCH_MODE_ONLY_SHELL) - - GNU make now has support for the Cygnus GNU WIN32 toolset. The - GNU WIN32 version of Bourne shell does not behave well when - invoked as 'sh -c' from CreateProcess(). The main problem is it - seems to have a hard time handling quoted strings correctly. This - problem goes away when invoking the Cygnus shell on a shell script. - - To work around this difficulty, this version of make supports - a new 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. - - A native WIN32 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%). - - If you wish to use Cygnus' GNUWIN32 shell, be sure you define - BATCH_MODE_ONLY_SHELL in the config.h.W32 prior to building make. - The new feataure was tested with the b18 version of the Cygnus - user tools. - -GNU make and 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 - - These caveats affect Windows systems only (Windows NT and - Windows 95) and can be ignored for other platforms. - - 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. - - 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-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, Windows 95/NT 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. - -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"). - - 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: - - subdir/Target: - touch $@ - - 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. - -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. - - Version 3.76 contains some preliminary support for FAT. Make - now tries to work around some difficulties with stat'ing of - files and caching of filenames and directories internally. - There is still a known problem with filenames sometimes being - found to have modification dates in the future which cause make - to complain about the file and exit (remake.c). - -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. - |