"David Abrahams" <dave@boost-consulting.com> wrote in message news:uodxr6mzi.fsf@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