Gennadiy Rozental wrote:
Robert Ramey <ramey <at> rrsd.com> writes:
One small point: I had this problem many years ago which prompted me to (reluctantly) sever dependency of serialization library from that of Boost.Test. It didn't totally solve my problem because the same issue occurred to some extent with other libraries.
It appear that given your approach to test against releases, you can actually use Boost.Test if you opt to.
I realized this immediatly when I switched my testing setup to trunk - serialization / release - everything else. And I considered going back to boost test. But by that time, there was no incentive.
It was unavoidable since I was testing the serialization library with other software in the boost trunk - which by definition/custom is experimental.
I realized that the real solution was to test the serialization library changes against the rest of boost on the release branch. It permited developers of prerequisite libraries from having to deal with me.
My point exactly.
Halleluhah - so I've one more person on board with this. That makes 3 so far - only 97 more to go!!! It's been some time since I used Boost Test. My complaint was that it wasn't idiot proof enough. I think this is the crux of the current complaint. Calls for "re-doing" boost test are sort of naive in my opinion and don't account for the huge amount of effort it takes to make something like this. Having said that, I guessing that "re-factoring" and "re-doing the documention" might be feasible and practical. This could be made easier by upgrading boost tools and practices. Stay tuned as I will have a lot so say and demonstrate on ths topic in the near future. I'm sure you can all hardly wait. Robert Ramey