-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, June 23, 2005 3:04 AM To: boost@lists.boost.org 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?
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
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
[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? threads, 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