Boost Testing :
From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2005-06-07 01:06:03
John Maddock <john_at_[hidden]> wrote:
>I think I've tracked down the problem: there's a cyclic header dependency,
>that only occurs for certain compilers:
>If BOOST_NO_IS_ABSTRACT is *not* defined, then:
>is_convertible.hpp includes is_abstract.hpp, which requires is_class.hpp,
>which *may* require is_enum.hpp, which requires is_convertible !
>Now, for every other compiler that doesn't define BOOST_NO_IS_ABSTRACT,
>dependency doesn't occur, because is_class uses SFINAE, rather than the
>any other type" approach.
So IIUC every compiler that does not defined BOOST_NO_IS_ABSTRACT currently
defines BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION, except for vacpp.
>So..... do the configure tests pass?
Apparantly so, following are the options added by configure (in user.hpp)
<user.hpp generated by configure>
</user.hpp generated by configure>
BTW, are these options necessary in *addition* to the options already used
or meant to be a config from scratch? AFAICT the latter, right?
> Do we need to define
>BOOST_NO_IS_ABSTRACT? If so then the problem goes away.
>Otherwise, if is_abstract works, then I'm assuming that SFINAE works also,
if SFINAE would'nt work, the configure script would define BOOST_NO_SFINAE
in user.hpp, right?
>and we can use the conforming version of is_class by defining
>BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION in the type_traits
>configuration (I think this macro should probably depend upon
>BOOST_NO_SFINAE, but it's too close to release to risk that change).
But what if we just test if we're working with the __IBMCPP__ compiler and
then define BOOST_TT_HAS_CONFORMING_IS_CLASS_IMPLEMENTATION in
type_traits/config.hpp, just like you do for GCC, MSVC etc.
>I think BOOST_NO_IS_ABSTRACT should be defined automatically when
>BOOST_NO_SFINAE is set as well, but again, I think that's one for after the
>Hope this helps to clear things up, and not muddy them further!
I'm hanging on ;-)