|
|
Boost Testing : |
From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-03-10 09:27:48
Vladimir Prus wrote:
>Aleksey Gurtovoy wrote:
>
> > David Abrahams writes:
> >> Martin Wille <mw8329_at_[hidden]> writes:
> >>
> >>>>>- the testing procedure is complex
> >>>> Internally, yes. The main complexity and _the_ source of fragility
> >>>> lies in "bjam results to XML" stage of processing. I'd say it's one
>of
> >>>> the top 10 issues by solving which we can substantially simplify
> >>>> everybody's life.
> >>>
> >>> I agree. This processing step has to deal with the build system (which
> >>> in complex itself) and with different compiler output.
Why does the BB output to XML processor need to handle compiler output? I
have a log file generator that outputs XML. All it does is filter the BB
commands into appropriate XML markup and outputs the data generated by the
tool invoked for that as:
<line><![CDATA[ ... ]]></line>
Therefore, you do not need to do any processing on that output. The only
place where this is slightly different is for the tests, where it strips the
BEGIN/END lines (and data after the END line).
With this in place, I then use XSL:T to further markup the compiler outputs:
adding hyperlinks, marking sections with ^^^ from CodeWarrior output in red
and a few other compiler-specific formatting rules. However, *this has
nothing to do with the XML generation* - you can do some _very_ neat things
with XSL:T!
> >> I've always thought that a design that gets information by processing
> >> stdout from bjam would be fragile. Furthermore, it means we can't use
> >> the -j option with bjam, which, even on uniprocessors, can speed up
> >> builds considerably. The build system itself should be writing the
> >> XML.
> >
> > Exactly. Is BoostBuild v2. going to give us that?
>
>Depends what you mean by "going". It's not a planned feature yet. And I
>think it's better to try to make V2 the official build system before adding
>any more features to it. After that, something should be possible.
I have already posted a tool that does this. Having the build system output
XML means that the build system needs to be careful not to have <, > or & in
the output generated by a tool it calls. You can put <![CDATA[ ... ]]>
around the output, but in order to do advanced processing on the output
(such as I am doing with XSL:T), you need to have XML tags for each line of
compiler output.
The alternative is to filter the output produced by the tool and do the < -
< conversion, but this requires capturing stderr and stdout for the
program being invoked.
Regards,
Reece