From:	huott AT pinebush DOT com (Ed Huott)
Subject:	Re: Make 3.75: Win32-Specific Fix for Filenames in Dependencies and i n Vpath
12 Feb 1997 04:13:58 -0800 :
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<199702120037.TAA12617.cygnus.gnu-win32@sol.pinebush.com>
Original-To:	"Griswold, Victor" <VGris AT aironet DOT com>
Original-cc:	"Cygnus:GNU-WIN32" <gnu-win32 AT cygnus DOT com>,
	"GNU: Make-Bugs" <bug-gnu-utils AT prep DOT ai DOT mit DOT edu>
In-reply-to:	Your message of "Mon, 10 Feb 1997 18:06:00 EST."
	<199702102309 DOT SAA08545 AT telxon>
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

In message <199702102309 DOT SAA08545 AT telxon>, "Griswold, Victor" writes:
>In the process of creating a software build environment which utilizes
>the cygwin32 tools, some difficulties arose in the use of 'make'.
>Specifically, DOS/Windows' use of ':' in filespecs confused 'make' both
>in dependency lines and in vpath lines.
>
>Since one of our goals is to have both our Unix and NT developers
>satisfied
>when working with the same build tools, I chose not to define 'MSDOS' in
>order to change the vpath 'PATH_SEPARATOR_CHAR' from a ':' to a ';'.
>That would break use of the Makefiles under Unix.  Instead, I followed
>what
>was already done under VMS for GNU make:  allow ':' to be "escaped" as
>'\:'.  A trivial $(subst :,\:,FILESPEC) then fixes up any DOS filespec,
>and does nothing to a Unix filespec.
>

The problems arising from ':' characters in path names could largely
be avoided through the use of UNC (Universal Naming Convention) names,
if only the cygwin32 tools could understand them!  If UNC names are
used, those pesky little ':' characters go away and you're no longer
at the mercy of potentially volatile drive letter assignments.

We use a native win32 build of GNU make 3.75 (which does understand UNC
names) and the fact that ' ' (space) can also be used as a VPATH
separator (instead of ':' or ';') in order to maintain a common set of
makefiles for our Unix and NT builds.  Of course, this only works for
us because we're not using the cygwin32 gcc and can avoid passing
fully qualified path names to any other cygwin32 utilities we do use.
(We use only relative path names in these cases.)

There are a couple of other considerations to take into account when
using UNC names:

1. If you want to build on a local drive, that drive must first be
made available as a network share, otherwise there will be no valid
UNC path to get there.  I understand that there may also a performance
penalty here because Windows isn't smart enough to take advantage of
the fact that the UNC path points to a local drive.

2. If you should happen to want to find out the current working
directory in terms of its UNC, you'll find this is an amazingly
difficult task.  I ended up having to write a special utility program
in C in order to be able to do this.  (WNetGetUniversalName() works
nicely, but only for network drives.  For local drives I ended up
having to search the shares table in the registry, mainly because the
WNet... family of enumeration functions seemed totally broken for
this.  Ugh!)  I can make this source code available to anyone who
might be interested.

<ED>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -