> 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
