Re: cmd.exe /c exists because of a compilation error transmitted by gnumake to the shell

[Eli Zaretskii]

> Date: Wed, 22 Feb 2006 15:11:51 -0800
> From: Cedric Perthuis <address@hidden>
> 
> I need to send back some data to my build manager too, so I need to 
> issue several commands at the same line. For example:
> "cmd.exe /c gnumake && pause"
> 
> if the build succeeds then my cmd.exe window will be left open on the 
> build server waiting for someone to press a key. This is fine, this is 
> exactly what I want, since instead of the pause I could execute some 
> more commands.
> 
> However, if the build fails: with a message like this one:
> "main.cpp
> win32\main.cpp(32) : fatal error C1083: Cannot open include file: 
> 'Rapi.h': No such file or directory
> gnumake: *** [../../tmp/win32/Debug/emviewer/win32/main.obj] Error 2"
> then the command "pause" is not executed.
> 
> I beleive that gnumake is returning an error ( I don't know how exactly 

Yes, Make exits with a non-zero status when it fails to build.

> and this error forces cmd.exe to exit before finishing the current 
> command line.

That's true; this is a feature of the "&&" operator: the second
command is run only if the first one exits with a zero status.

> So my problem is not entirely due to gnumake. it's mainly a cmd.exe.
> For instance if I do "cmd.exe /c asdsadsadasdada && pause" cmd.exe will 
> say something like command not found and will exit without calling the 
> pause.
> The thing here is that my build command is completely valid, the fact 
> that the build fails is something else, that I want to handle myself.
> so is there a way to configure gnumake not to output an error which 
> makes cmd.exe to exit ?

You can cause Make to exit with a zero status by prepending a `-' to
the command(s) that can fail.  But this is not recommended, as you
generally don't want Make to ignore failed commands.

> and I am wondering if someone has a workaround or have tackkle the pbl 
> differently.

Yes, there is a way: use & instead of &&.  & will always run the
second command, even if the first fails.