Mail Archives: djgpp/1998/04/10/02:01:42
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--
- Raw text -