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

[Ricardo Wurmus]

Mark H Weaver <address@hidden> writes:

> Ricardo Wurmus <address@hidden> writes:
>
>>> on “core-updates” the “gtkglext” package fails with an odd error
>>> message: […]
>>
>> It seems that this is not limited to “gtkglext”.  This behaviour seems
>> to affect any package using “invoke” where the invoked command fails.
>>
>> Should the build system catch the exception and make sure that it gets
>> to print “build phase `foo' failed”?
>
> In my opinion, it's not important for that message to be printed.  What
> is being printed now is far more informative, and sometimes that extra
> information is quite useful.
[…]
> Also, even if we catch the exception and do a nice job printing it, we'd
> likely lose the backtrace to the original error, which in some cases
> might be quite useful.

Since the build system itself uses invoke to run “make” any error
encountered during the build phase looks something like this:

--8<---------------cut here---------------start------------->8---
Backtrace:
           4 (primitive-load "/gnu/store/vrv8gx4s940z0vaaq9a40jsq9xf…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
    640:9  2 (for-each #<procedure a4bbc0 at /gnu/store/qzsljkcllc0…> …)
In 
/gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/gnu-build-system.scm:
   799:31  1 (_ _)
In 
/gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm:
    616:6  0 (invoke _ . _)

/gnu/store/qzsljkcllc01dmdq9z0yrqri3ajam3vp-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#<condition &invoke-error [program: "make" 
arguments: ("-j" "4") exit-status: 2 term-signal: #f stop-signal: #f] 9a61c0>)'.
builder for 
`/gnu/store/2yn2kz4vdfxrrm8lcxfkfbx2548rrmd6-powertabeditor-2.0.0-alpha10.drv' 
failed with exit code 1
--8<---------------cut here---------------end--------------->8---

It doesn’t seem like this information is actually useful.  I see here
that make failed, which is obvious because we are in the build phase.  I
don’t see why it failed.  I could do without the information that the
“gnu-build-system” uses invoke internally, because “invoke” is not at
fault here.

Previously, we had the phase return #f, which allowed us to cleanly
exit, inform the observant user about the phase that failed (this is
useful because the name of the phase may have long scrolled out of the
buffer), and exit.  The backtrace for invoke does not seem to add
anything of importance and it obscures the actual error.

> 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?

What do others think?

--
Ricardo