Re: [boost] Boost.config not recognize threading support enabled?

From: John Maddock (john_at_[hidden])
Date: 2005-06-23 05:04:01

> [Dick] My primary reservation about this approach is based upon my
> assumption that the "macro-that-identifies-linux-on-arm" would be an
> attribute of the compiler.  I still can't get used to the idea that
> multi-threaded or single-threaded is compiled into the gcc
> cross-compiler itself, while little-endian and big-endian are command
> line switches. %>[  The multiplicity of targets and threading models
> might require a number of such tests that would be difficult to manage.

Sure? _GLIBCPP_HAVE_GTHR_DEFAULT tells you whether the compiler and std lib 
were compiled with threading support or not, as long as the change is 
limited to linux on arm, just how many such tests would we need?

>> Any closer?
>
> [Dick] I'm of two minds about the following suggestion:  it's either a
> kludge or introduces a certain pleasing symmetry. ;)
>
> Since BOOST_DISABLE_THREADS is used to unconditionally disable threads,
> the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same
> place in suffix.hpp) would [almost] unconditionally define
> BOOST_HAS_THREADS - subject only to the existing verification that the
> threading API has been identified and is recognized.

Or you could just spell your new macro BOOST_HAS_THREADS :-)
No changes needed then.

John.