Re: [boost] Re: Boost.Test online?

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