summaryrefslogtreecommitdiff
path: root/README.W32
diff options
context:
space:
mode:
Diffstat (limited to 'README.W32')
-rw-r--r--README.W32338
1 files changed, 179 insertions, 159 deletions
diff --git a/README.W32 b/README.W32
index 60025d0..e311170 100644
--- a/README.W32
+++ b/README.W32
@@ -1,4 +1,5 @@
-This version of GNU make has been tested on Microsoft Windows 2000/XP/2003.
+This version of GNU make has been tested on
+Microsoft Windows 2000/XP/2003/Vista/7/2008.
It has also been used on Windows 95/98/NT, and on OS/2.
It builds with the MinGW port of GCC (tested with GCC 3.4.2).
@@ -6,6 +7,23 @@ It builds with the MinGW port of GCC (tested with GCC 3.4.2).
It also builds with MSVC 2.x, 4.x, 5.x, 6.x, and 2003 as well as
with .NET 7.x and .NET 2003.
+As of version 4.0, a build with Guile is supported (tested with Guile
+2.0.3). To build with Guile, you will need, in addition to Guile
+itself, its dependency libraries and the pkg-config program. The
+latter is used to figure out which compilation and link switches and
+libraries need to be mentioned on the compiler command lines to
+correctly link with Guile. A Windows port of pkg-config can be found
+on the Windows download page of the GTK+ project:
+
+ http://www.gtk.org/download/win32.php
+
+The libraries on which Guile depends can vary depending on your
+version and build of Guile. At the very least, the Boehm's GC library
+will be needed, and typically also GNU MP, libffi, libunistring, and
+libtool's libltdl. Whoever built the port of Guile you have should
+also provide you with these dependencies or a URL where to download
+them.
+
The Windows 32-bit port of GNU make is maintained jointly by various
people. It was originally made by Rob Tulloh.
@@ -37,10 +55,16 @@ 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.
+ The batch file will probe for Guile installation, and will build
+ gnumake.exe with Guile if it finds it. If you have Guile
+ installed, but want to build Make without Guile support, type
+
+ build_w32.bat --without-guile gcc
+
Building with (MSVC++-)cl using build_w32.bat or NMakefile
----------------------------------------------------------
@@ -51,16 +75,21 @@ 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).
+ The batch file will probe for Guile installation, and will build
+ gnumake.exe with Guile if it finds it. If you have Guile
+ installed, but want to build Make without Guile support, type
+
+ build_w32.bat --without-guile
-------------------
-- Notes/Caveats --
@@ -68,212 +97,203 @@ 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 2
- limitations:
-
- - The number of concurrent processes has a hard limit of 64,
- due to the way this port implements waiting for its
- subprocesses;
-
- - The job server method (available when Make runs on Posix
- platforms) is not supported, which means you must pass an
- explicit -jN switch to sub-Make's in a recursive Makefile.
- If a sub-Make does not receive an explicit -jN switch, it
- will default to -j1, i.e. no parallelism in sub-Make's.
+ 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-3.82 (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-4.0 (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, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
-2006, 2007, 2008, 2009, 2010 Free Software Foundation, Inc.
+Copyright (C) 1996-2013 Free Software Foundation, Inc.
This file is part of GNU Make.
GNU Make is free software; you can redistribute it and/or modify it under the