From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-19 15:04:27
At 01:29 PM 8/18/2002, Gennadiy Rozental wrote:
>> Thank you for the information. A helper header might be nice, though
>> you might just add a macro like BOOST_CPP_MAIN to
execution_monitor.hpp,
>> which is reminiscent of the old system. Either solution would be fine
>> by me.
>
>After some consideration I see following two chooses:
>1. I could try completely mimic Boost.Test V1 interface/functionality.
>This solution includes:
> a. Introduce boost/test/cpp_main.cpp, which in fact will be forwarding
>header that includes
> boost\libs\test\src\cpp_main.cpp and
> boost\libs\test\src\execution_monitor.cpp
> b. Make test_tools.hpp to handle BOOST_INCLUDE_MAIN (or some other
more
>descriptive name).
> If BOOST_INCLUDE_MAIN is defined test_tools will implement some
>limited lightweight functionality
> similar to what Boost.Test v1 was doing.
>
>This solution could be deprecated in a future, when it is not used
anymore
>
>2. I could introduce 2 new headers to support online (no library) testing
> a. boost/online/prg_exec_monitor.hpp
> This header will include
> boost\libs\test\src\cpp_main.cpp and
> boost\libs\test\src\execution_monitor.cpp
> b. boost/online/test_exec_monitor.hpp
> This header will include everything current online_test is
>including.
>
>This solution could be permanent. It will work and support the same set
of
>features as offline version.
Always hard to know what others want, but I'll take a shot at it.
* People don't want their existing code broken. That's like mom and apple
pie, but what I hadn't realized in the Boost.Test context is that if you
break their makefiles, jamfiles, IDE projects, scripts, etc, that is just
as bad as breaking their C++ code. I also underestimated the number of
people using V1.
* Some people need and want a full-featured test library, including unit
tests. (V2 looks good to deliver on that.) AFAIK, there haven't been any
requests from this group for header-only compilation.
* Some people need and want a minimalist test library, not including unit
tests. (V1 was fine for that.) Header-only compilation is important at
least as an option for this group. At least some in this group do not want
the complication of features they don't use. It is important to recognize
that these more minimalist wants/needs aren't something to be deprecated or
ignored now or in the future. They are a permanent part of the userbase.
* Some people need and want a execution monitor, not including testing at
all. (V1 was fine for that.) Header-only compilation is even important as
an option for this group. Most in this group do not want features they
don't use, period. It is important to recognize that these wants/needs
aren't something to be deprecated or ignored now or in the future. They are
a permanent part of the userbase.
Those needs seem to me a lot more like your option 1, but permanent rather
than as a deprecated feature.
Maybe it just won't work to have one developer and library support three
somewhat separate use scenarios. But there is so much conceptual overlap it
seems a shame to split them into separate libraries.
We really need a decision on this right away, unfortunately.
--Bemna