Re: 3.81 and windows paths

[Eli Zaretskii]

> Date: Fri, 28 Jul 2006 17:31:31 -0400
> From: "Paul D. Smith" <address@hidden>
> Cc: 
> 
> Hm.  I just can't think of any but the most obscure cases where this is
> true.  The DOS pathname handling in vanilla GNU make, as far as I know,
> is very specific: if and ONLY if the first character of a pathname is a
> letter and the second is a colon, then the path is considered a DOS
> path.  The only constructs where the meaning is ambiguous would be very
> rare; something like:
> 
>     foo : c:bar
> 
> should this be interpreted as a static pattern rule:
> 
>     foo : c : bar
> 
> or with the DOS path "c:bar"?  In this case it's obvious to us since the
> latter leads to a syntax error but of course make doesn't know that when
> it's parsing tokens.
> 
> 
> Any ambiguity is trivially solved by adding whitespace before and/or
> after the ":" in target rules.

Target rules is one case; another is values given to PATH and
VPATH/vpath/GPATH, where a colon is the separator on Posix platforms.

> I suppose there might be some backslash issues.  I really don't remember
> what HAVE_DOS_PATHS does with backslashes in target/prerequisite
> pathnames.

When HAVE_DOS_PATHS is defined, Make tries very hard to treat
backslashes and forward slashes in file names in the same manner.  The
only case I remember where we intentionally do NOT treat backslashes
as forward slashes is in the $wildcard function (and in fact in any
other situation that calls `glob' or `fnmatch').