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

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-06-27 12:14:10

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On
> Behalf Of John Maddock
> Sent: Thursday, June 23, 2005 3:04 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.config not recognize threading support
enabled?
> 
> > [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?

[Dick] Nope, not sure at all.  I overlooked "limited to linux on arm".
(At any given time our "build" currently uses six instances of gcc -
various PowerPC, x86 look-a-likes, DSPs, etc. - and I'll worry about
those later.)  Yes, your suggestion to put the test in libstdcpp3.hpp
seems like it would work nicely.  As a no-longer-lurking newbie, can I
do something or do I sit back and wait for someone to add that test?

> >> 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.
 
[Dick] Once again I yelled before I was bit.  I'm haven't been able to
get bjam --v2 to pass BOOST_HAS_THREADS to the compiler so I ass-u-me-D
it was some magic cookie that was being #undefD in preparation for use
as a flag.  Dumb.  I'll go back to the boost.build list with this now.
Thanks for the mentoring.

> John.
> 
[Dick] Regards,
Dick