Re: [boost] Regression test / compiler status progress

From: Rob Stewart (stewart_at_[hidden])
Date: 2002-07-10 12:45:38

From: "William E. Kempf" <williamkempf_at_[hidden]>
>
> From: "Rob Stewart" <stewart_at_[hidden]>

> > Boost isn't likely to post XML with a reference to an external XSLT
> stylesheet,
> > expecting the browser to perform the transformation.

> I don't know... this is a simple solution.  There's pros and cons, and
> you're probably right that we'd be better off  providing a fully transformed
> HTML file using an XSLT transformation utility, but the pros and cons should
> at least be discussed.

Reasonable.

> PROS

> * Simple implementation.

No argument.

> * Doesn't require "lengthening the tool chain".
>    * Release process isn't complicated by another set of scripts needed to
> transform the XML.

If you choose to create HTML reports to post at the web site, then this must be
done.  I think we're saying about the same thing.  I just figured you'd want it
to happen automatically, at least for the web site.

>    * Boost users can produce their own reports using only tools they're
> likely to have already (C++ compiler, Jam and a "modern" web browser).

Sure.  I hadn't considered that aspect of generating the results.

> CONS

> * If the user doesn't have a "modern" browser he can't view the transformed
> report.

The other problem is which browser you target with the resulting HTML.

> >  Instead, I expect that
> > Boost will generate the HTML as a normal step in the regression test
> build.

> No, I'd expect the HTML generation to be a seperate step.  This way users
> with out an XSLT transform utility can still run the regression tests.  Even
> if they don't have a) a "modern" browser or b) an XSLT transform utility,
> they could still read the resultant XML file.  Also, this makes it so that
> Boost doesn't have to pick an XSLT transform tool that all users (who want
> to run regression tests) must agree to.

That's fine.  I wasn't thinking at that granularity.

> > Therefore, there doesn't seem to be a compelling reason to use XSLT over a
> > scripting language with SAX2.

> The compelling reason to me is that we can keep the dependencies on tools to
> a minimum, both for the Boost release process and the Boost user base.
> Using XML and XSLT gives maximum flexibility with minimum requirements on
> tools.

If the person writing the transformation is more comfortable with Python and
SAX2 (I'm assuming Python support, here), then I don't think we should impose
XSLT.  If that person must learn new stuff either way, then I, too, would favor
XSLT.

> Generating XML is trivial... it's format is human readable, similar to HTML,

It can get painful to read if care isn't taken to include appropriate newlines,
but otherwise you're correct.

> and easily rendered using simple iostream output.  Once a structure is

I'd encapsulate that functionality in some RAII classes that insert opening and
closing elements automatically because it will make generating well-formed XML
easier.  Such classes would need to allow inserting attributes, too, so you'd
need to pass them to the ctor -- at least for a simple implementation.  There's
probably something already available to make that easy anyway.

Rob