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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-05-27 19:35:03

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

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

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

>>>> Now you propose to have different default behavior on different
>>>> platforms. I would strongly oppose such inconsistency (And don't
>>>> forget there other reasons mentioned in this thread to keep current
>>>> default).  Regression tools maintainers (and/or library developers)
>>>> need to decide what they want to do on case by case (tool by tool or
>>>> even better test/tool by test/tool) level.
>>>
>>> I fundamentally disagree that is the ideal.  It's one of the
>>> major goals of Boost.Build and the testing framework built around it
>>> to centralize expertise about platforms, tests, compilers, etc., so a
>>> library developer does _not_ need to be an expert in every platform,
>>> compiler, etc. that his library may run under. One should be able to
>>> use high level abstractions to describe what needs to be accomplished,
>>> and allow the knowledge of platform-specifics embedded in the
>>> framework to take care of the details.  So far, we've been pretty
>>> successful.  However, if Boost.Test doesn't cooperate with that
>>> approach, it will either undermine the effort, or we will have to stop
>>> using it in the Boost regression tests.
>>
>> 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.

>> What you propose:
>>
>> 1. Make library behavior inconsistent for regular user
>
> Depends what you're measuring.

I measure library behavior in regular (non-extreme)  circomstances.

>> 2. Make some users that actually prefer existing default unhappy
>> 3. Will change the default that is used currently
>> 4. Cause new users not get best from the library until they will learn
>> advanced options
>
> Depends how you measure "best."
>
>> 5. Doesn't present an ultimate solution for regression testing:
>> whatever default is chosen for any platform it still may stall.
>>
>> 6. Could be implemented on regression tool/library Jamfile level without
>> causing 1,2,3,4
>
> How so?

Specify in appropriate tools files (or testing.jam) additional CLA for 
running tests.

>> 7. Is trying to solve a problem for very few users by causing different
>> problems for many others
>
> The way things are going, your clients among Boost library developers
> (who may need this feature) will continue to dwindle.

Funny thing is that you don't propose solution that would address this need 
(simply because there no one IMO)

>> If you so adamant that signals should not be caught,
>
> I am not.  I am adamant that the library design and its integration
> with the Boost testing system should be responsive to the needs of
> Boost regression testing,

I am responsive. I don't think that Boost.Test is the one that needs to be 
fixed.

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

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

Gennadiy