stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Black <>
Subject Re: bulletproofing exec output
Date Thu, 02 Aug 2007 22:34:08 GMT
Greetings Martin

I suppose I should elaborate on the third option I put forward, in a
more general manner.  One of the long-term plans for the exec utility,
as I understand it, was to allow for alternate output modes, such as an
'interactive' mode, which would include such sugar as colored output and
run timeout countdown and the verbose output mode.

What I picture is a structure where an arbitrary set of output mode
files can be dropped into the bin directory and compiled into the exec
utility.  It ideally would be possible for the makefiles to
automatically determine which files are output mode files, and each
output mode module would add itself to an internal list of mode modules
as part of the runtime initialization.  A certain number of modules
would ship with stdcxx (including the default and verbose modes, along
with the 'interactive' mode after it's written), and end users would be
able to write other modules of their own devising, if they wished.

With this structure, we would be able to write a module of our own,
designed for the nightly testing infrastructure, add it to the testing
source tree overlay, and specify that the exec utility should use the
new module, rather than the default output.

--Andrew Black

Martin Sebor wrote:
> Andrew Black wrote:
> [snipped descriptive summary]
> ...
>> Looking at the output (as it stands now), I believe the parsers could be
>> more robust if they ignored all lines that started with whitespace or
>> where the first word was in all caps.  Alternately, they could start
>> processing after the first line in all caps, and stop processing before
>> the second line in all caps.  I suppose a third option would be to alter
>> the exec utility so it could produce the output desired, rather than
>> doing a post-processing step.  Thoughts?
> IMO, since exec already has all the data the post-processing stage
> works so hard to compute it might as well write it out in a format
> that's easy to parse by the script you're talking about. I.e., the
> summary would be it. The other script that I was referring to is
> the cross build view generation script that actually needs the
> individual examples, locales, and tests, and doesn't care (yet)
> about the summary.
> So if take this approach we need to "standardize" both the output
> format for the individual programs as well as the summary. The
> summary format currently looks like this:
[snipped sample output and initial problem]

View raw message