Re: [boost] [test] Broken header (via indirect #includes)

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-14 13:28:54

On Jul 14, 2008, at 7:48 AM, David Abrahams wrote:

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

When you suggested to check the trunk, I wondered how could I check  
if I couldn't find the code before.  Then that and the floating point  
comparison policy reminded me to check how I handled this for the  
Boost.Rational tests.  When I checked, I handled the problem the same  
way.  I guess this isn't a bug; I forgot that this is a design  
decision, just like the floating point comparison case.  Sorry.

Of course, one could strongly argue that this design decision is a  
bug itself....

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com