Mail Archives: djgpp/1998/04/09/06:17:50
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.
- Raw text -