Date:	Thu, 20 Apr 95 13:26:47 EDT
From:	den AT aisinc DOT com (Dave New)
To:	UCKO AT VAX1 DOT ROCKHURST DOT EDU
Subject:	Re: Bug in DJGPP make
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu

 
> >Your mention of COMSPEC provided the key, though.  By setting the environment
> >var COMSPEC=C:\BIN\SH, I was able to start 'make distclean' from the DOS
> >command.com prompt, and the makefile invoked the MKS versions of sh and rm and 
> >seems to work OK.
> 
> Actually, I never seriously considered changing COMSPEC because I figured
> it would break too many other programs.
> 
> --- Aaron Ucko

Actually it does 8-(

I found out that if you Ctl-C out of the make, you run the chance that
command.com had been flushed from memory, and then the system fails to find
it to reload it (used to be DOS didn't really pay any attention to the COMSPEC
string, but it's been 'fixed' in some previous release).

Anyway, I found that by setting COMSPEC to the MKS shell and setting the SHELL 
var in the makefile to the right path to the MKS shell, I could get the clean 
targets to work.  So, after the make 'distclean', I would put the COMSPEC back 
to the command.com, then run 'configur', followed by 'make', which would 
re-compile everything.  Takes about 28 minutes on a DX2-66 with 16 MB of RAM.

I found that if left the SHELL and COMSPEC modified to C:\bin\sh, that the make 
would run strangely -- it would behave as if I had typed 'make -n'.  It would 
just load the compiler, but then exit quietly without doing anything!  It would 
take about ten minutes to run through the make this way, and no objects would 
be built.  It also didn't seem to know what to do with the command /c 
mklibnow.bat-type state-ments in the make.  They seemed to exit immediately.

I guess the answer is that the makefile DOS build targets have been modified to 
run under command.com, but the clean targets haven't -- they use things like if 
-- fi, rm, and others that are clearly not in the DOS domain.  They worked for 
me because of the presence of the MKS toolkit.

Does this mean that the makefile configure for DOS is defective, or is this just
operator error on my part?  I wouldn't think that I would need other 386-
executable GNU toolset (or Un*x clone) stuff running to get the compiler 
re-compiled (except for go32, the compiler itself and the GNU make) --- is this 
not a correct assumption?

This is all preparatory to re-configuring the compiler to produce i960 code.
Hopefully, this will not bring down another whole host of problems.

DaveN

- Raw text -