|
|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2006-05-21 18:18:09
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:ufyjdhqcg.fsf_at_boost-consulting.com...
>>>
>>> I don't know about the default (how do you plan library would
>>> figure out whether it's run from regression run or by hand?), but
>>> users could specify how they want library to behave using either
>>> CLA or environment variable (or in config file starting next
>>> release)
>>
>> I'm not sure whether it's the right kind of specification, though.
>> Is it? What I'm looking for is a specification that says, "run the
>> test so that a regression test is least likely to halt, whatever
>> that means on this particular system/compiler," not "run the test
>> with signal handlers that throw exceptions."
>
> This kind of specification make sence for regression tool options
> decision.
I don't know what "regression tool options decision" means.
> On library level that is used by regression tool one need to provide
> an options for both alternatives.
Probably.
> Enforcing different defaults on library level on different compilers
> completly unacceptable IMO. Library behavior should be consistent.
Sure, but it all depends on what you mean by "behavior." You measure
behavior by the answer to "do the signal handlers throw exceptions?"
Other people measure behavior by the answer to the question, "does the
test terminate without user intervention."
>>>> 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.
>>> 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. For me, barriers to writing
tests have to be extremely low, because I just have too many other
things to think about.
>>> 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?
> What you propose:
>
> 1. Make library behavior inconsistent for regular user
Depends what you're measuring.
> 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?
> 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.
> 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, 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.
> 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.
-- 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