|
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,
>this
>dependency doesn't occur, because is_class uses SFINAE, rather than the
>"not
>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.
Right?
>
>So..... do the configure tests pass?
Apparantly so, following are the options added by configure (in user.hpp)
<user.hpp generated by configure>
#define BOOST_MSVC6_MEMBER_TEMPLATES
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_STDINT_H
#define BOOST_HAS_SIGACTION
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#define BOOST_HAS_PTHREAD_DELAY_NP
#define BOOST_HAS_PARTIAL_STD_ALLOCATOR
#define BOOST_HAS_NL_TYPES_H
#define BOOST_HAS_NANOSLEEP
#define BOOST_HAS_MACRO_USE_FACET
#define BOOST_HAS_LONG_LONG
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_DIRENT_H
#define BOOST_HAS_CLOCK_GETTIME
#define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
</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
>
>release.
>
>Hope this helps to clear things up, and not muddy them further!
I'm hanging on ;-)