Date: Thu, 9 Apr 1998 13:15:57 +0300 (IDT) From: Eli Zaretskii To: "Edward F. Sowell" cc: djgpp AT delorie DOT com Subject: Re: When in Rome... In-Reply-To: <352BBDA7.7D2BFE29@home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 8 Apr 1998, Edward F. Sowell wrote: > The suggested workarounds are (a) use \\ or (b) use /. Well, there are > cases (like mine) where neither will really work. These cases are usually rare, unless you insist on using DOS programs which don't understand forward slashes, like MOVE. Even then, you can use the built-in $(subst) function to convert the slashes. > Apparently, the / are not converted to \ for DOS commands. 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. > 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. > This, for me, is intolerable, > since my code must be built with other compilers and make programs too. In general, DOS versions of Make are highly incompatible with each other. The syntax of extensions like `include' directives, special tricks to support long command lines etc. are very different. Thus, I don't believe you could craft a non-trivial Makefile which will work with more than a single version of Make. The usual practice is to have a separate Makefile for every toolchain. > But, for those of us who were hoping for a public domain C++ > environment for apps born and raised in Dos/Windows, it really > doesn't meet the need. You can download some auxiliary tools from the DJGPP site and use them instead of the stock DOS commands. For example, use `mv' instead of `move', `rm' instead of `del', `cp' instead of `copy', etc. Then everything will work for you, including the slashes, long command lines and a lot more. These programs understand both forward- and backslashes, so if you need to use both styles of slashes, you can do that as well. > Unfortunately, it has taken a couple weeks out of my life to > discover this. I'm sorry about the loss of your time. I would suggest in future to ask the question about such problem earlier. Anybody who has spent a few days banging their head against a problem is well entitled to post a question here about that problem. I would also like to point out that the README.dos file distributed with the DJGPP port of Make specifically advises to avoid using backslashes as much as you can, and explains why. > That is, when > in Unix I do as the Unix world dictates, avoiding the temptation to try > force Unix to work with DOS/Windows syntax. Shouldn't those who port > Unix to Dos/Windows be doing acting in kind? I am the one who's to blame: I did the ports of the 3 latest releases of GNU Make. I agree that it would be nice to support backslashes as well as slashes. Other GNU packages which I ported usually have full support of both style of slashes. While porting Make, I added support for backslashes in several places (like the built-in file-name- oriented functions), where that was feasible. But supporting backslashes throughout proved to be very difficult, and I couldn't afford making it happen. Personally, I don't believe it can be done at all. The backslash as quote character is deeply entrenched in Unix-born Makefiles, and some of the features of GNU Make will surely break by such a change. Since the DJGPP port is the only DOS/Windows Make that can run Unix-born Makefiles with almost no changes (provided you install some auxiliary tools, as I mentioned above), I doubt that somebody would agree losing features to support inferior tools where better tools are freely available. > If there is something I'm missing that will cause me to retract the > above analysis, I'd like to hear about it. My main question is: why won't you use additional DJGPP-ported tools which support both styles of slashes, instead using stock DOS commands? These tools are freely available from the same place you donwloaded the port of Make, so everybody can have them for free.