Date:	Mon, 08 Jan 1996 15:55:48 -0600
From:	Rob Tulloh <tulloh AT tivoli DOT com>
Organization:	Tivoli Systems Inc.
To:	djgpp AT sun DOT soe DOT clarkson DOT edu, roland AT churchy DOT gnu DOT ai DOT mit DOT edu
Subject:	GNU ported to Windows/NT (native WIN32)

Howdy,

I have ported GNU make 3.69 and GNU make 3.74 to Windows NT.
I am interested in turning over the changes I made back to
the maintainers - if the maintainers are interested that is :-).
Would you be interested in getting this ported code
from me? At Tivoli, we use GNU make to build hundreds of source
files that produce 2GB of object and executable code (in
a debug build). GNU make is critical to our porting work
on Windows/NT. We make extensive use of GNU make features including
using VPATH/vpath to locate source and objects on different drives.

I did an initial port to NT using Datafocus' NutCracker, but now 
that we are a tad more saavy with NT, I
ported the command directly to NT using MSVC 2.2 and WIN32 calls
(no NutCracker). AFAIK, as long as you have a working shell,
you can safely use this version of make. We are in progress on
enhancing GNU bash to work for us in this regard (we need all
the functions of the Unix version in the NT version of bash).
For now we are relying on a port of NetBSD 4.4 sh using NutCracker.
I suppose you could use MKS sh.exe, or the NT ResKit (POSIX) sh.exe
as alternative shells (I cannot confirm this though).

I did the port using 3.69 sources because this is the frozen
version of GNU make that we use on all the other platforms
(AIX, HP, SunOS, Solaris, DG, OSF/1, UnixWare, etc.) we compile on here 
at Tivoli.  I also ported in parallel the 3.74 sources because:

	a) it had #ifdef __MSDOS__ code which I looked at for clues
           as to where #ifdef WIN32 code should go.
	b) this version might be more interesting to users of GNU make who
           want the latest release.

If you would like a copy of my source tree, just send me an e-mail and
I will gladly send you a gzip'ed tar file. I did the port using Visual
C++ projects, but this could easily be converted back to a vanilla Makefile.

The 'process' code in my port utilizes a little library I created called
subproc.lib which is purely a wrapper to make CreateProcess() easier
to use. I only ran into one major stumbling block in the port that had
to do with the directory/file caching code in dir.c. It looks like the
lookup_file() function can get confused when processing vpath data if
a long-running make process populates a directory with files after the
directory has already been visited and cached. I fixed this by using stat()
to check if the st_mtime was newer than the last visit and forcing make
to reconsider populating the cache with files it had not seen before. I
wonder if this might not be a problem common to the Unix version as well
and it just is hidden somehow. I didn't investigate that deeply to find out.
All the rest of the changes had to do with the normal headaches associated
with NT (slash direction, drive letters, UNC paths, environment handling,
delimiters, fork/exec) -- pretty straight forward stuff. 

Anyhow, I hope to hear back from you.

Cheers!

Rob

-- 
Rob Tulloh        | TIVOLI Systems, Inc.            | Phone: (512) 794-9070
                  | 9442 Capital of Tx Hwy, North   | FAX  : (512) 794-0623
                  | Arboretum Plaza One Suite 500   | DID #: (512) 502-4662
tulloh AT tivoli DOT com | Austin, TX 78759, USA           |

- Raw text -