From: John Maddock (boost.regex_at_[hidden])
Date: 2003-08-29 06:49:51
> 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?
Yes, the default user.hpp does nothing and delegates everything to to the
boost.config system, ultimately they should both end up setting the same
options allbeit by different means.
> 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).
Threading support is on when BOOST_HAS_THREADS is defined, and off when it's
not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of
these mentioned in the configure generated user.hpp (and in the config
docs).
John.