|
|
Boost Testing : |
From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-01-22 12:21:40
Roland Schwarz <roland.schwarz <at> chello.at> writes:
>
> Nicola Musatti wrote:
> > Roland Schwarz <roland.schwarz <at> chello.at> writes:
> >> If so, I think this is the wrong way to go, since it would give
> >> misleading regression reult pages.
> >
> > Why? The serialization library was explicitly developed to allow this
> > possibility for compilers that are not supported by the current Spirit
> > release. Spirit 1.6 itself is still being more or less maintained just
> > for this purpose.
>
> Ok, fine. So there ought to be a easy to comprehend recipe for
> regression runners how to cope with this case. A regression runner
> shouldn't IMHO be exposed to a lot of custom setup. I, as is my case, am
> not currently involved much with spirit, so would have lot of time
> getting started. I am primarily interested in Boost.Thread development.
First of all note that I'm not the author of the serialization library, I merely
helped Robert Ramey with Borland related issues. I wish I had the kind of recipe
you wish for, but I've yet to find out what's the best way to deal with this.
The switch to Boost.Build v2 is proving to be too much for my limited spare
time. As for Robert, I believe he gave up on 1.34, exactly for this reason. On
the other hand, judging from his test results from a while ago, Anthony Williams
appears to have set this up properly.
> Also how would a user of the library see then whether everything will
> run "out of the box" or will need custom setup? She can't do this by
> mere looking at the regression results. But perhaps I am
> misunderstanding something here.
I haven't looked for a while, but the serialization documentation used to
explain this.
> > With Boost.Build v1 the serialization library was set up to either allow in
> > place replacement of the Spirit subtree or to detect an external
> > installation of Spirit 1.6 by means of an environment variable. That's how
> > tests for the Borland compilers have been run since Spirit 1.8 was
> > integrated into Boost.
>
> Please put me on track: Why isn't the Boost.Spirit at the appropriate
> level then?
Spirit 1.8 makes a more advanced use of the language than 1.6, which proves to
be too much for less compliant compilers like Borland's.
> > I feel that if a library author is willing to devote effort to backward
> > compatibility he should rather be encouraged than hampered.
>
> Humm, yes. But why put the load on the regression runners then?
> Regression runners mainly contribute CPU cycles, not development. Isn't
> this the duty of the library author to make everything as smooth as
> possible? Preparing a suitable run of regressions is part of these
> duties. Not?
I understand your point of view. On the other hand relieving the runners of this
kind of problem would require a level of coordination and dependency management
that I don't think is achievable out of people's spare time.
When all's said and done it's up to each regression runner to decide which
optional paackage to install: it shouldn't be that different with Python,
GraphViz or ICU, for instance.
Cheers,
Nicola Musatti