This is the mail archive of the
mailing list for the Cygwin project.
Re: 3.81 and windows paths
> Date: Fri, 28 Jul 2006 17:31:31 -0400
> From: "Paul D. Smith" <firstname.lastname@example.org>
> 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
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').
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html