Re: [AD] mingw make is bad.

[Henrik Stokseth <hensto@xxxxxxxxxx>]

Eric Botcazou wrote:

> > seems like the recent make utility that comes with mingw-2.0.0 is
> > seriously screwed. it wrongly sets UNIX_TOOLS on the MSYS test ($SHELL
> > is not set), and it also croaks on the first command of make -n, which
> > is a simple echo!?! the problem it seems is that make tries to execute a
> > command directly instead of opening it in a subshell as it should. i've
> > also tried out different make programs, no luck. sad, in msys everything
> > works like a dream.
> >    
>
> What's the version? I have no problem with make 3.79.1 packaged as 
> make-3.79.1-20010722.tar.gz.
shit! i figured it out, there's nothing (seriously) wrong with mingw 
make. searched on my hd for sh.exe and found one in \winnt\system32, i 
didn't know i had one there. i must have copied it from an earlier 
cygwin installation for some reason.

the problem in detail for those interrested: mingw make uses sh.exe 
instead of command.com/cmd.exe if it can find it, it totally ignores 
$SHELL on startup. it also sets $SHELL to sh.exe or whatever other shell 
that is used, that in turn causes the msys test to kick in defining 
UNIX_TOOLS. the original bourne shell doesn't have the echo command 
built in like the bourne again shell has, so it searches for an echo.exe 
from gnu textutils. it wasn't installed in my path so the makejob errors 
on the first command (echo). i'm used to bash, that's why i didn't 
realise it at first. also this behaviour is inconsistent with section 
6.9 of the gnu make manual. (the default behaviour is to ignore $SHELL 
on startup except on DOS or windows, on those platforms $COMSPEC is used 
if not $SHELL is set)

--
One OS to rule them all,
one OS to find them,
one OS to bring them all
and in the darkness bind them.