This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Make 3.75: Win32-Specific Fix for Filenames in Dependencies and i n Vpath


In message <199702102309.SAA08545@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@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]