Message-ID: <352CE547.134248F@home.com> From: "Edward F. Sowell" MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: When in Rome... References: Content-Type: multipart/mixed; boundary="------------456518C307ADD617028880DE" Lines: 227 Date: Thu, 09 Apr 1998 15:11:25 GMT NNTP-Posting-Host: cc984399-a.flrtn1.occa.home.com NNTP-Posting-Date: Thu, 09 Apr 1998 08:11:25 PST Organization: @Home Network To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk This is a multi-part message in MIME format. --------------456518C307ADD617028880DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks to all who responded to my complaint. I'll address suggestions made by several here. First, some background. I have a rather complex build process since it includes parsing user input that results in selection of files to be compiled and linked, as well as generation of a file to be compiled and linked. The package is to run on a variety of platforms and hopefully with a variety of compiler/make/etc tools. We seek to disturb the user's life as little as possible, i.e., avaid telling him/her "you must buy MSVC++," when he/she already has Borland installed. Moreover, we believe that the user should not have to replace his/her existing tools, e.g., make program, command shell, etc., with "special ones" to make our software work. The task cannot be done with the (small, as you note) common subset of make features in Borland, MS, Symantec, and GNU. Also, we decided to try to avoid loading the user's environment with environment variables and path additions, and instead use a preference file in which ALL environment information is kept... sort of like the .env file DJGPP uses. These decisions led us to a C++ build program that reads the preference file, constructs a make command string, and spawns the make process. To deal with the variable list of compile/link modules, another C++ program is launched from the makefile, and this program spawns a sequence of other makes, using the same makefile. We have been modestly successful with this approach. A single makefile works for Borland, Symantec, and MS 4 and 5. Some modifications were needed to make it work on Linux with gcc and GNU make. However, the approach is on the rocks with the DJGPP on DOS/Windows. But I still have hope. I should also say that due to the richness of GUN make, our build CAN be done without our C++ programs, if we abandon our preference files; we have done that on Unix. Perhaps we should abandon our approach and simply ask our users to download the fileutils, GNU make, etc, and even replace his/her command.com with bash. But somehow I find that distastful. One should not ask users to change their whole system to install a new piece of software. Below, I respond to your comments. But let me say in advance that I very much appreciate what you (and others in this forum) have told me. Further comments would be appreciated, if you feel so moved, but none are necessary. I have had my say. Ed Sowell Eli Zaretskii wrote: > > 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. > I will look into subst. > > 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. > Somehow, Borland, MS, and Symantec make programs deal with \. Surely this is not impossible with GNU make. > > 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. > > 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. No one knows this better than I. See my discussion above. > > > 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. I may have to do this. > > > 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. > Please forgive me for my remark. It was ill considered. > > 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. I'm sure many people do appreciate your efforts; please include me in that number. But I somehow hoped that DOS/Wimdows users could be better accomodated without compromising the (much greater) needs of Unix "porters." > > > 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. See my earlier remarks. Perhaps I am wrong, but I don't believe that that porting software to another platform means converting that platform to Unix. --------------456518C307ADD617028880DE Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Edward F. Sowell Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Edward F. Sowell n: Sowell;Edward F. adr;dom: 1207 N. Van Buren St.;;;Placentia;California;92870; email;internet: sowelled AT home DOT com tel;work: 714-278-3291 tel;fax: 714-278-7168 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------456518C307ADD617028880DE--