Re: make does not stop on error

[Eli Zaretskii]

> From: "grischka" <address@hidden>
> Date: Tue, 2 May 2006 16:12:08 +0200
> 
> The one seems indeed a change in make behaviour whether or not
> it stops when the -include target cannot be made. Example:
> 
> ----- makefile
> all: T1 T2
> T1:
>     exit 101
> T2:
>     exit 202
> 
> -include T2
> 
> ----- make 3.79.1:
> exit 202
> ~c:\mingw\bin\make: *** [T2] Error 202
> -->(2)
> 
> ----- make 3.81.90:
> exit 202
> exit 101
> ~make: *** [T1] Error 101
> -->(2)

This is a change in Make, unrelated to the Windows port, since I get
the same difference between 3.80 and 3.81 on GNU/Linux.

Paul, is this true that there has been a change in behavior in this
regard?  I could find nothing about this in NEWS, FWIW.

> Here is an example for what can happen with the batch files:
> - make 3.81.90 from recent cvs
> - built with nmake -f NMakefile
> - run on windows ME
    ^^^^^^^^^^^^^^^^^
This is expected on Windows 9x and ME: their stock shell COMMAND.COM
doesn't return a meaningful exit status (always, not only when it runs
batch files).  On Windows XP I get the expected result:

    nocc -c 1.c -D "X"
    'nocc' is not recognized as an internal or external command,
    operable program or batch file.
    make: *** [1.o] Error 1

If we want to consider the Windows 9x case, then replacing the batch
file with "$COMSPEC /c" will not solve the problem, since the Windows
shell on those systems _always_ returns a zero exit status, whether it
runs a batch file or other commands/programs.

> > In any case, even if the exit code is always zero, I could never
> > explain the ``background'' part of that report.  Can you?
> 
> Well, say for instance you have 'make -C src' in a toplevel makefile. 
> Then if this process is killed the hard way, the sublevel processes 
> are left running. 
> 
> Example:
> 
> ---- makefile.test:
> all:
>     ./sleepy -sleep "10"
> 
> ---- rxvt (msys tools):
> address@hidden /c/test/make/make-m
> $ ./make -f makefile.test
> ./sleepy -sleep "10"
> ---> zzrr.. 9
> ---> zzrr.. 8
> ---> zzrr.. 7
> 
> address@hidden /c/test/make/make-m
> $ ---> zzrr.. 6
> ---> zzrr.. 5
> ---> zzrr.. 4
> ---> zzrr.. 3
> ---> zzrr.. 2
> ---> zzrr.. 1
> ---> zzrr.. oops
> 
> The proggy sleeps for one second each step. After '7' I pressed 
> Ctrl-C. Make is killed and rxvt shows the command prompt. Then 
> output continues until time is over.
> 
> Note that this would not happen when you hit Ctrl-C in the original 
> windows console, but its common with GUI programs that use pipe 
> redirection.

Well, I'd say this is probably a bug in rxvt.  Ctrl-C on Windows is
funny: if you write a signal handler for SIGINT in a console
applications, when Ctrl-C is hit, the system creates an additional
thread to run the signal handler in it, while the original main thread
still runs(!).  (You will see that in the current Make code, I added a
fragment to explicitly stop the main thread while the signal handler
runs, to emulate the Posix behavior, without which the two threads
will step on each others' toes.)  It is possible that the ported rxvt
doesn't handle this correctly, or maybe it (or the shell that it runs)
catches SIGINT in a way that interferes with the default behavior of
sending SIGINT to all the subprocesses as well.

So I don't think this is a problem with Make.  If you can show
evidence to the contrary, please share it.