Subject: Re: bug#10431: a .trs file left behind for each test

From: Stefano Lattarini <[email-masked]>
Date: Wed, 04 Jan 2012 17:59:49 +0100

tags 10431 notabug
close 10431
thanks

On 01/04/2012 04:10 PM, Jim Meyering wrote:
> Hi Stefano,
Hi Jim, thanks for the report.

> [using latest automake from git.master]
> For example, in grep and coreutils, after I run "make check", I find
> that every test has a corresponding .trs file alongside the usual .log file.
>
Yep, that's by design; the new automake-generated testsuite harness needs
to register, for each test script that it runs, more information than the
simple "final result" of the script.  It would have been really awkward and
fragile to do so "in band", i.e., with special directives embedded into the
`.log' files[1]; so we register this new information safely out-of-band,
into these `.trs' files (where "trs" stands for "Test ReSults").  This new
interface should be clearly documented in 'master' version of the automake
manual; if something is missing or unclear, that's a bug, and feel free to
report it!

[1] I had taken the in-bad approach initially:
     <http://lists.gnu.org/archive/html/automake-patches/2011-06/msg00199.html>
    but it proved brittle and bug-prone (as predicted by Ralf); hence the
    introduction of the `.trs' files:
     <http://lists.gnu.org/archive/html/automake-patches/2011-07/msg00097.html>
     <http://lists.gnu.org/archive/html/automake-patches/2011-08/msg00001.html>

> Those are indeed removed via "make clean", but shouldn't they be removed
> also upon normal completion of each test?
>
Oh no!  The testsuite harness will need them to perform various tasks; e.g.,
the creation of the final `test-suite.log' file, the display of the testsuite
summary, the decision of which files to re-run upon "make recheck", etc.

HTH,
  Stefano

P.S. Let me reiterate that, while I greatly appreciate your continual use
and testing the bleeding-edge automake versions with real-world packages,
the code from `master' it is IMO *not* stable or mature enough for use in
production code.  So I'd advise against its use in the upcoming coreutils
release (but you could use the version from maint, which has a couple of
bug fixes w.r.t. 1.11.2, and it's IMHO very stable).