Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-28 08:57:33


"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

>>>> For me, barriers to writing tests have to be extremely low, because
>>>> I just have too many other things to think about.
>>>
>>> I worked very hard on usebility last couple releases. I don't see
>>> how it could be done easier for users at the moment.
>>
>> I think that job isn't finished yet. I keep hearing from people who
>> try to use the test library and are frustrated (I'm sorry, I'm not
>> naming my sources).
>
> Could you at least present reasons for their frustration?

For example:

  anonymous: why do i need a separate .lib?
  anonymous: <sigh>
  anonymous: my needs are very simple
  anonymous: boost.test is too complicated
  anonymous: the minimal test framework met my needs

>>>>> Library developers doesn't need to know anything in most cases. I
>>>>> would assume that it's regression tools developer/maintainer
>>>>> responsibility in most cases.
>>>>
>>>> Okay; does Boost.Test give the regression tools developer/maintainer
>>>> the means to control this option?
>>>
>>> Yes it does. Using CLA and environment variables. Next release it will
>>> support config files either.
>>
>> Then we should be able to set the options conditionally in the Boost
>> testing framework, to reduce the likelihood of hanging. That's good
>> news.
>
> That's what I am trying to say is the best solution IMO - set it up in
> either tool or testing.jam

Great, but...

>>>>> why don't you just set this options for all test automatically in
>>>>> Boost.Build?
>>>>
>>>> Because I'm already overwhelmed with other responsibilities, and
>>>> don't posess the domain knowledge to do it.
>>>
>>> I don't mean you personally. I mean Boost.Build developers.
>>
>> I think, to the extent to which an interaction with Boost.Test
>> behavior causes the problem, the information about how to set the
>> options should be maintained with Boost.Test. Also, it should be
>> included in the Boost.Test documentation, because Boost won't be the
>> only project with the same issues.
>
> Yes this need to be covered in docs.

...given that fact, it seems obvious to me that the test library
maintainer should take responsibility for maintaining that setting in
the build/test framework.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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