Boost logo

Boost :

From: troy d. straszheim (troy_at_[hidden])
Date: 2005-09-26 07:15:41


I have infrastructure built to do portability testing. It is a lot of
changes, flexible, and turned on by command line switches. I know this
doesn't help the current emergency, and I'm buried in chasing down bugs
in the portable archive that I've found since I can now give it the full
battery of serialization tests, and since I need to deliver this archive
type ASAP, I can't switch to trying to do something intelligent about
overall testing time within serialization. I am collecting ideas, and
trying to refactor things as I go to prepare for this "something
intelligent".

But for now, maybe switch from carpet bombing to running only
polymorphic xml archive (static), and non-archive-specific tests? It's
a quick hack to the Jamfile, would cut the run time down by 1/6 or so
and still get pretty good coverage.

Testers could also get immediate relief by running with
-sBOOST_ARCHIVE_LIST=xml_archive.hpp to get the same effect.
(Apologies if that's obvious.)

-t

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:
>
>
>>I should note that the serialization library changes only very
>>infrequently - maybe once every few weeks.
>>
>>I would question re-runing the serialization library tests just because
>>something that the serialization library depends upon changes.
>
>
> We can talk about global policy changes after you fix the emergency.
> It's a lot harder to change the way we do testing and the rest of our
> infrastructure than it is for you to simply reduce the number of tests
> being run.
>
> Please do what's required to bring the overall Boost testing time back
> down to something reasonable.
>
>
>>A main cause of this problem bjam dependency analysis re-runs all tests on
>>Library X even if library X hasn't changed.
>
>
> No it doesn't.
>
>
> To reiterate:
>
> Anything that makes it very difficult and/or expensive for a tester
> to complete a testing run needs to be fixed rather urgently.
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk