| delorie.com/archives/browse.cgi | search |
> Date: Fri, 28 Jul 2006 17:31:31 -0400 > From: "Paul D. Smith" <psmith AT gnu DOT org> > 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'). -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |