|
|
Boost Testing : |
From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-01-22 09:10:18
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.
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.
> 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?
> 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?
Roland