|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-07-14 07:48:20
on Sun Jul 13 2008, Daryle Walker <darylew-AT-hotmail.com> wrote:
> 1. BOOST_AUTO_TEST_CASE_TEMPLATE is #defined in "boost/test/
> unit_test_suite.hpp"
> 2. This template depends on boost::type and
> boost::unit_test::ut_detail::template_test_case_gen
> 3. template_test_case_gen is defined in "boost/test/
> test_case_template.hpp", which happens to #include "boost/type.hpp"
> 4. Neither of the appropriate headers are directly #included in
> "unit_test_suite.hpp"
> 5. I guess that one or both headers were indirectly #included in
> "unit_test_suite.hpp", but that indirect header purged the headers I
> needed, and the author _forgot_ that another header was counting on
> the old indirect #include.
>
> I worked around the problem for now by directly #including "boost/
> test/test_case_template.hpp" in my test file.
>
> But I shouldn't have to do this.
>
> Worse, this has happened before with Boost.Test, in regards to the
> floating point comparison tests. Those test macros called a function
> that wasn't in the same header, nor #included; i.e. the user has to
> add an extra #include for the floating-point test macros to work.
> The floating-point incident was a deliberate design decision, but I
> guess that my problem here was caused by accident.
>
> The point: DIRECTLY #include everything a macro needs in that macro's
> header. I'm sick & tired of hunting all the extra headers I need.
> Worse, I'll have to re-hunt when my test program craps out if/when
> the author re-arranges all the macros & headers.
>
> My point [5] is only a guess because I wasted two hours searching the
> trac/subversion site for where & when the author broke the build. I
> didn't find it, and I figured that I shouldn't have to.
>
> When you fix this, let me know so I can remove the extra #include from
> my test file.
>
> (Apologies in advance if the real problem is that my subversion
> working copy is severely fried.)
Daryle,
Thanks for diagnosing this. Please put a ticket about this at
http://svn.boost.org. If you could check the boost trunk (using the
Trac browser it should be easy) first to make sure that it's not fixed,
that'd be a bonus.
Thanks again,
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk