On 3/24/2014 3:07 PM, h.becker wrote:
There are several problems with the checked-in old exit handling, which
aren't resolved by the recently suggested new code.
Old problems are:
- the %NONAME-?-NOMSG messages, which are generated by VMS when a
program returns a Unix style exit code; an exit code 2 shows as
%NONAME-E-NOMSG, Message number 00000002.
- VMS style warnings do not stop make.
New problems are:
- redirecting exit (and _exit, which seems wrong) to vms_exit, where the
passed exit code is adjusted, doesn't really know whether this is a make
exit code or one passed from an action routine, which can be of any style
- in case of an error there are error numbers printed by make, with the
adjusted exit codes, these numbers are no longer obvious.
That is because the conversion is not complete, only the parent handling
has been fixed, not the child status.
Documented Make exit codes are 0, 1, 2 and VMS style exit codes are 0
for success, and VMS style failure codes start at 8 for Access violation.
The CRTL decc$exit() and decc$_exit() are already doing a translation of
exit code 0 to be SS$_NORMAL.
So 0 is passed through to decc$exit, and codes 1 through 7 need to be
encoded as POSIX exit codes.
And after looking at how MAKE_TROUBLE works, as you had it, it does need
to have an ERROR severity level. A warning status should stop the make,
but since the target actually got created, re-running make should
continue. Since MAKE_TROUBLE is returned when a target is not created,
re-running the make should result in a failure again.
I am now able to run the complete test suite, and while not everything
passes, I can now see the impact of using the POSIX encoding is, and
where more adjustments are needed.
For programs that never see VMS status codes, the _POSIX_EXIT macro
definition fixes almost everything. But we can not use it on GNU make
because we need the VMS exit codes and want the VMS severity codes for
backwards compatibility.
I have not submitted my latest exit handling patch because I am waiting
for the GNU copyright assignment. It has been a week now, and I have
not seen a response.
It seems that having VMS specific codes for MAKE_SUCCESS, MAKE_TROUBLE
and MAKE_FAILURE is the way to go. Easy, as long as these codes
are always used. But there are hard coded numbers 0, 1 and 2 as well as
EXIT_FAILURE, passed to die() and/or exit().
That may introduce other problems if Make or a child is using the hard
coded number instead of the symbol.
It is safer to have the exit() do the encoding, and that is more
transparent to majority of the maintainers to make.
The less VMS specific code they have to work around, the better. And
the less chance that they may break something VMS specific by accident.
So I suggest to always use the MAKE_mumble macros and to define them for
VMS as posix compatible exit codes. This avoids redirecting exit to
vms_exit; this assumes that the exit status of a child process is VMS
style, which makes checking for failure simpler; this allows to decode
and print the known make error numbers.
If we were compiling /DEFINE=_POSIX_EXIT, then all this happens
magically, except then we can not set the VMS severity bits.
But it doesn't solve everything. The usual action routines will be VMS
utilities which set the VMS style exit codes. Any program which adheres
to the VMS style exit codes will work as an action routine as well. That
includes all programs which make use of the posix compatible exit codes
as well.
Action routines, which just return a Unix style number, would need
different checks. Although it seems simple to check for zero (when there
is no VMS facility code set), it turns out that the child processes, as
they are implemented today, never ever return zero. This way it is not
possible to find out whether it was successful or not.
That is already being handled in the lib$spawn. lib$spawn is returning
the VMS status in a VMS specific variable, so the VMS status which
includes POSIX encoded status.
There is some extra handling needed in the VMS specific code around
LIB$SPAWN to decode the POSIX status back to the original UNIX code.
That will make the numbers reported by Make look like they should. Once
that is done, then the original UNIX constants for MAKE_<mumble> will
match the output.
The only case that is problematic to handle is when a child utility
ported from Unix using UNIX exit codes is not compiled with
/DEFINE=_POSIX_EXIT/MAIN=POSIX_EXIT. In that case, 0 and 1 are both
treated as 1, and the rest of the numbers get passed through.
I have been through this conversion on the VMS Perl project which has
similar backwards compatibility issues.
Regards,
-John
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
