Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Edward F. Sowell" , djgpp AT delorie DOT com From: Nate Eldredge Subject: Re: When in Rome... Date: Fri, 10 Apr 1998 18:49:52 -0700 Message-ID: <19980411014943.AAD28260@ppp127.cartsys.com> Precedence: bulk At 03:11 4/9/1998 GMT, Edward F. Sowell wrote: >> Make cannot convert the slashes because it doesn't have the slightest >> idea which commands understand or don't understand forward slashes. >> Even more significant, Make doesn't know which arguments are file >> names and which aren't. Clearly, changing '/' into `\' in strings >> which aren't file names would be disastrous. >> > >Somehow, Borland, MS, and Symantec make programs deal with \. > Surely >this >is not impossible with GNU make. Of course it is not impossible, it just can't be done without breaking existing Makefiles. GNU Make uses '\' as an escape character to prevent special interpretation of the following character, and this behavior has come to be expected of it. Changing it would be an awful lot of work and destroy compatibility. > >> > Suppose that make is interacting with other >> > programs that read and write path strings from/to files, and invoking >> > system functions, e.g., file opening, etc. What am I to do then? I am >> > lead into a constant changing of code and data files, "\\" to "\" for use >> > by the system functions and back to "\\" for make. >> >> I don't understand this problem. I think using "\\" is indeed ugly, >> but it should work. No conversion to single "\" is required, because >> Make itself strips the leading "\" leaving only one when it invokes >> subprograms. If you see cases where this fails, please post an >> example. >> > >Suppose the path string has \\ in it to make GNU make happy. Now suppose >that I use this same string as the argument in the istream.open() >function. >It will fail, since open() knows nothing about the \\ business. In which case the program that mungs the preferences file (or wherever the file name comes from) into the Makefile will have to do that replacement if DJGPP is being targeted. I assume it already has to do some kind of '/'->'\' conversion, right? Nate Eldredge nate AT cartsys DOT com