[ANN] Make-3.77 binaries for Mingw
Brendan Simon
brendan@dgs.monash.edu.au
Sun Aug 8 21:54:00 GMT 1999
Mumit Khan wrote:
> Since folks keep on asking for a recent port of Make, I built my local
> copy of 3.77 (tiny config changes, and no source changes at all) for
> Mingw. Completely unsupported (read: emailing me bug reports is a waste
> of time ;-).
>
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports/make-3.77-mingw32.zip
>
> I'm appending the README.make file also available from the ftp site above.
>
> Regards,
> Mumit
>
> MAKE-3.77 for Mingw
> Sun Aug 8 19:15:38 CDT 1999
> =====================================================================
> This is GNU make 3.77 compiled with gcc-2.95 for Mingw. Hardly tested
> on either Win9x or NT, so expect bugs and problems. Comes completely
> unsupported.
>
> Comes with make.exe binary and documentation in GNU info and HTML
> formats.
>
> Changes to make-3.77:
> - Unlike in previous ports, I've left _beginthreadex and _endthreadex
> intact, and instead used MSVCRT runtime to build make 3.77.
>
> - I've added a Makefile.mingw32, and will submit the changes to the
> make maintainer in due time.
>
> Does it work? Well, enough to build itself and also my other test cases.
> The one that still gives me problems is the "cd some/dir"; I'm using the
> -C switch to sub-makes instead.
>
> Mumit Khan -- khan@xraylith.wisc.edu
> http://www.xraylith.wisc.edu/~khan/
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports/
>
> ==== here's the README.win32 from make-3.77 distribution + my few lines.
>
> Port of GNU make to Windows NT and Windows 95
> Builds natively with MSVC 2.x or MSVC 4.x compilers or with Mingw GCC.
>
> 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
>
> To build with GNU make on Windows NT or Windows 95 with GCC:
>
> 1. Make sure you egcs-1.1.2 or newer GCC for Mingw installed.
> The current release at the time of this writing is gcc-2.95
> ( http://gcc.gnu.org/ for more info). The only gotcha is
> that some of the code in w32/subproc assumes the use of
> MSVCRT runtime, not the default CRTDLL runtime. That means
> that you'll need to update your runtime. See:
> http://www.xraylith.wisc.edu/~khan/software/gnu-win32/
> for instructions on how to change your runtime to MSVCRT.
>
> 2. You must have a copy of a recent GNU make port for windows32
> (Cygwin/Mingw/UWIN/etc).
>
> 3. make -f Makefile.mingw32
>
> Outputs:
> 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.
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
I'm a bit concerned about how bug free MAKE-3.77 is. The mainters of Enoch (Pentium
optimized linux distribution. http://enoch.masslinux.com/ ) claim that they had heaps
of problems with make-3.77. When they rolled back to 3.76.x, all things built fine.
This was mentioned on there web page for the pending 0.7 release of Enoch, but has
since dissappeared now that 0.7 has been released.
I'm not sure how much to read into this for cygwin users, but I imagine that most of
the problems would also be present for cygwin users. Just thought that I would
mention it and if any one else has any versions of make that they recommend or not
recommend then please let the list know.
Brendan Simon.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
More information about the Cygwin
mailing list