[boost] Re: 1.30.0->1.30.2: no more thread support for Linux?

From: Steve Hutton (shutton_at_[hidden])
Date: 2003-08-28 21:22:06

In article <04c301c36d5b$ebc2ce90$b2c66b51_at_fuji>, John Maddock wrote:
>> Any thoughts on more explicitly documenting the #defines used to toggle
> optional
>> features in header-only boost modules?
> 
> What where you thinking of other than that already in
> www.boost.org/libs/config/config.htm

I was thinking of a view from the point of view of each individual
library.  e.g., the shared_ptr docs mention what to define to 
turn off thread support on a boost that was configured with thread
support on, but I didn't see a specific explanation of what to define to
turn thread support on without Boost Config.  

>> Boost Config seems to hide those details fairly effectively for developers
>> who don't distribute their code (or distribute Boost along with their
> code).
>>
>> The problem I see is that developers who distribute code that depends on
>> boost can't count on the user's version of Boost being configured in any
>> particular way (or at all - the docs suggest just untarring it as a valid
>> way to use the header-only modules).
> 
> There shouldn't really be any difference between the config after just
> extracting the tarball, and after running configure.

Maybe I'm missing something - when I run boost/libs/config/configure, it
adds #defines to user.hpp.  Presumably Boost Config does something similar,
correct?

< // options added 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_YIELD
< #define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
< #define BOOST_HAS_PARTIAL_STD_ALLOCATOR
< #define BOOST_HAS_NRVO
< #define BOOST_HAS_NL_TYPES_H
< #define BOOST_HAS_NANOSLEEP
< #define BOOST_HAS_LONG_LONG
< #define BOOST_HAS_GETTIMEOFDAY
< #define BOOST_HAS_DIRENT_H
< #define BOOST_HAS_CLOCK_GETTIME

If these defines were just for boost implementation details/optimization it
wouldn't concern me, but it seems as though in some cases they change the
way Boost will interact with my program (e.g., shared_ptr and thread safety).

Steve