www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/01/11/22:11:37

Date: Thu, 12 Jan 1995 11:27:33 +0900
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: tim AT pi DOT la DOT tce DOT com
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: bug in djgpp's make

Guys:
    I've no intent to offend, but let's give credit where credit is
due.  Or the reverse....

   >In short, I haven't tried this lately with 
   >another make but I am not sure it is a bug, just a gotcha!

   I've tried it with Gnu make under Unix.  The Djgpp behavior is a bug.

"The Djgpp behavior is a bug."  Accurate, but imprecise.  The DJGPP
behavior is a bug in COMMAND.COM.

   Our makefiles often run for an hour.  Failed commands don't always
   cause the commands that depend on them to fail, so it's important for
   make to stop because otherwise the wrong output is produced and nobody
   notices.

GCC does not guarantee that other programs that it must cooperate with
will behave rationally.  COMMAND.COM is an example of an irrational
program.  Making FSF programs behave like Unix programs under DOS
requires *extensive* changes to the source (somewhere).  Thus, it is
the very compatibility of GNUish programs' *behavior* with the
*behavior* of FSF programs under Unix that leads to the
source-mangling that causes GNUish programs to be GNU-ish, and not
supported by the FSF.  (Well, RMS does have a stubborn, blind,
pig-headed, irrational, and 100% justifiable aversion for MS-DOG.  But
note that DJGPP is now official wares of the FSF.)

Now, redirection is sufficiently useful in Makefiles that one wants a
mechanism to deal with this.  An alternative to munging the Make
sources which is acceptable to the FSF is to provide appropriate
library support.  So system() can do its own redirections.  How about
aliasing, variable substitution, etc, etc?  By the time Morten is
done, the code for system() will be a superset of bash(1)!!  Why do
this when system() can just call the shell?

Yes, I know, this breaks your Makefiles.  But changing system() to
emulate the shell is going to break the makefile of everyone who uses
4DOS or ms_sh, and what happens under OS/2, Windowze, and NT?  Eg, I
use an alias 'cp=copy' under 4DOS.  (The cp.bat solution failed for
me, I forget why.)  Unless system() is smart enough to look in my 4DOS
environment, all makefiles which use 'cp' are going to fail.  That is,
unless system() passes unrecognized programs to the shell for
handling.  In which case you are still going to have your problem.

I'm willing to accept the "system() emulates shell" solution.  It will
be a severe pain in my butt (I'll have to change a couple of deeply
embedded makefile habits, which are reinforced frequently by
programming under Linux), and may well chase me away from DJGPP
entirely, except to beta test certain packages which are used with
DOS+DV/X+DJGPP.  (I program quite a bit, but primarily for my own use.
So Unix-to-DOS portability is not really that important to me, except
for the stuff I beta test.)

Even if I were going to continue in DJGPP for the foreseeable future,
I'd accept this solution.  But the issue is not as black-and-white as
you seem to think.

    --Steve <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019