bug#31647: [core-updates] gtkglext fails in a weird way

[Mark H Weaver <mhw@netris.org>]

Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> In summary, although the new messages don't look as nice in common
>> cases, I think it's more important to ensure that we have the
>> information we need to debug the occasional non-obvious problem.  So, I
>> think we should leave it alone :)
>
> I think we should strive to make the common case look good.  Can we
> achieve this without making the exceptional case harder to debug?  Can
> we caught the exception triggered by standard build phase invocations of
> “make” but not those of custom “invoke” expressions in custom build
> phases where the error message could be useful?

I appreciate your perspective on this, and you've made some good points.

How about this idea: in core-updates-next, we could add code to
'gnu-build' in (guix build gnu-build-system) which catches &invoke-error
exceptions thrown by the phase procedures.  This is a very common case,
and I agree with you that a backtrace is rarely (if ever) useful for
that particular exception type.  The program name and arguments included
in the condition object should be enough information.  We could use a
copy of the code from (guix ui) to print the invoke errors nicely:

            ((invoke-error? c)
             (leave (G_ "program exited\
~@[ with non-zero exit status ~a~]\
~@[ terminated by signal ~a~]\
~@[ stopped by signal ~a~]: ~s~%")
                    (invoke-error-exit-status c)
                    (invoke-error-term-signal c)
                    (invoke-error-stop-signal c)
                    (cons (invoke-error-program c)
                          (invoke-error-arguments c))))

However, I would prefer to catch *only* invoke errors, and to let most
exception types go unhandled by gnu-build.  If you can think of another
exception type that should be handled more gracefully, please let me
know.

What do you think?

      Mark