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" Original-cc: "Cygnus:GNU-WIN32" , "GNU: Make-Bugs" 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. - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".