|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 20:21:12
"Rene Rivera" <grafikrobot_at_[hidden]> wrote in message
news:4664A688.7030101_at_gmail.com...
> Gennadiy Rozental wrote:
>> "Rene Rivera" <grafikrobot_at_[hidden]> wrote in message
>> news:46649B3C.4060204_at_gmail.com...
>>> Douglas Gregor wrote:
>>>> On Jun 4, 2007, at 5:06 PM, Gennadiy Rozental wrote:
>>>>>> * We don't test release versions, even though this is the most used
>>>>>> variant by users.
>>>>> We shouldn't be doing this at all IMO. NO testing during release.
>>>> I believe Rene means the "release" variant, i.e., with optimizations
>>>> turned on. This also saves a *ton* of disk space. Also, testing with
>>>> shared libraries rather than dynamic saves a lot of disk space.
>>> Yes, I mean building and testing with optimizations on. Most likely we
>>> would want to build the profile variant so that we could get both
>>> optimizations and debug symbols. But that introduces the large disk
>>> space requirements again. My point is that we currently *only* test what
>>> is useful to library authors. And we essentially give users the cold
>>> shoulder.
>>
>> From what I understand there is no problems adding these tests into test
>> suite.
>
> Your understanding is incorrect.
You mean Boost.Build doesn't support it?
>> No "boost-wide" decision is required.
>
> We need to decide that the optimized variant is a release requirement.
1. It's kinda orthogonal to the whole "development environment" problem. If
you believe it's required - it is going to be required in any case.
2. In my personal opinion release variant shouldn't be release requirement
boost wide. Each developer may decide for oneself. I don't insist though.
> Then we need to acquire testing resources for each platform we support.
> Then we need to manage the testing resources to cover both debug and
> release for all platforms such that we get timely testing results. And
> we need to ensure that library authors fix all the places where the rely
> on testing only in debug mode. We've gone over this before, so I suggest
> people search the testing and dev list archives.
Test resources management is important but separate topic IMO.
>> We may just add encouraging
>> statement to the testing procedures docs.
>
> Encouraging isn't enough. We have to explicitly ask if we want anything
> approaching a reliable procedure.
I am afraid it's never ending story. Some users require "release
variant". Some require static libs some require shared libs. some require
level of optimization 4, some 2. And what about all this different STLs we
got around.
In general IMO we *shouldn't* strive to test against any possible user's
environment.
Users will have to run unit tests we provide and report issues if there are
any. Library developer than may add the test case and fix it.
Gennadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk