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

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-05-21 10:34:00

"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. 
On library level that is used by regression tool one need to provide an 
options for both alternatives. Enforcing different defaults on library level 
on different compilers completly unacceptable IMO. Library behavior should 
be consistent.

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

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

>> 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. What you propose:

1. Make library behavior inconsistent for regular user
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
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
7. Is trying to solve a problem for very few users by causing different 
problems for many others

If you so adamant that signals should not be caught, why don't you just set 
this options for all test automatically in Boost.Build? Let's see how many 
complaint you get.

Gennadiy