On 3 June 2014 06:10, David Golden <x...@xdg.me> wrote: > While that's occasionally useful, it bloat the amount of data sent and > stored. The decision taken a while back is only to provide results > from the last phase to run.
I'm with demerphq. The origin of the error would have been evident during the compilation phase, when the compiler would usually printed a lot of warnings as it tried to compile and found that "HvRITER_set" was not defined. The error message on loading the module, which is what demerphq got, is pretty irrelevant here. I understand that all the information from all phases is not usually necessary, but in the case of failures, it's next to impossible to debug what went wrong on the particular computer. I have one machine where one module of mine is failing, and I have absolutely no idea what can possibly be happening there since the error messages I get are not detailed enough: http://www.cpantesters.org/distro/J/JSON-Parse.html?grade=3&perlmat=2&patches=2&oncpan=1&distmat=1&perlver=ALL&osname=ALL&version=0.30 In another case I introduced a completely bogus test into a module just so that I could get basic environment information by printing it out as the "test result" using a trick "skip all if": https://metacpan.org/source/BKB/Image-PNG-Libpng-0.37/t/bogus.t For people writing XS modules, test results without the compilation information are a kind of not-so-enjoyable puzzle or mystery. We can't reproduce the problem on our own systems, and the information is not enough to work out what went wrong. We also cannot control the compiler's options with OPTIMIZE in "Makefile.PL" without breaking the module on many systems. For example if you set OPTIMIZE up with "-Wall -Werror" so that the compilation fails on error, then your module will fail to compile on Solaris and Windows even if there is no problem with the module, due to the different C compiler. I would like to suggest that a test failure is accompanied by more detailed information, especially for XS modules.
