Re: [boost] [filesystem][program_options][serialization][test]fromcomp.lang.c++.moderated

From: David Abrahams (dave_at_[hidden])
Date: 2006-05-28 01:01:21

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

>> "David Abrahams" <dave_at_[hidden]> wrote in message 
>> news:uodxr6mzi.fsf_at_boost-consulting.com...
>>>>>> maybe this mode specification thing is even unnecessary, I don't
>>>>>> know.  But if you know which platforms and compilers will benefit
>>>>>> from mapping signals, it seems to me you should only do it there.
>>>>>
>>>>> IMO all users on all platforms could benefit from signal catching
>>>>> (both in regression run and run by hand).
>>>>
>>>> Clearly Martin was not benefitting.
>>>
>>> In this particular case. In some other cases he will (IMO)
>>
>> Not if he gives up on the library before he ever gets to those cases.
>
> I don't see how I could help it without breaking consistency in library 
> behavior.

Sometimes a break with consistency is a pragmatic and appropriate
thing to do.

>>>>> At the same time the same users need to understand the
>>>>> possibility (small IMO) of hung test in case of severe memory
>>>>> corruption.
>>>>
>>>> This was apparently not a small probability for Martin.  He said
>>>> it happened dozens of times.
>>>
>>> Maybe for the same particular test. I personally never have any
>>> problems with it. Did you?
>>
>> Of course not.  But I mostly avoid the test library.  Its default
>> behaviors are well-suited to a relatively large investment in
>> learning, framework, and automation.
>
> I don't think it's true. The only real problem is lack of proper 
> documentation.

Without proper documentation it requires at least a large investment
in learning.  And even if the perception that a large investment in
framework and automation is required is wrong, without proper
documentation such perceptions will persist.

>> 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).

>>> 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.

>> and especially responsive to reports of showstopper bugs.  It's
>> neither good for Boost.Test nor good for Boost as a whole if
>> libraries like Spirit end up feeling compelled to dump the use of
>> Boost.Test.
>
> I agree. Why don't we at least try to consider what I propose?

Had to understand it first :)

>>> 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.

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