From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-05-27 19:35:03
> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>>> 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
>>>> 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
> 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
>> 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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk