I'm just a lurker/user, but speaking from the perspective of someone who writes code that uses boost that customers compile, defaulting to *BOTH* single and MT would sure make my life easier. IMHO, the extra build time may be important to silicon-based life forms, but eliminating the learning, explanation and maintenance that falls to various carbon units involved would more than make up for it. Maybe default=both for 1_31_0?
<intended-to-be-humorous level='mild'> Besides, everyone knows that it's the apps that are important and are compiled over and over - this is JUST THE LIBRARY that makes it work! </intended-to-be-humorous> <previous> > > > > Agreed. Still, this doesn't imply you shouldn't _also_ provide > multi-threaded libs by default. I mean, what is it to you if > there's libboost_filesystem_mt.a, libboost_regex_mt.so, etc. for > multi threading, while you can simply use -lboost_regex when > linking your single threaded application? > I don't have a problem with that, except that it increases the size of the build and the time taken. But its not a big issue as you can always control whats done through the build system. > The default build is single threaded, while there's also by default a > Boost.Threads build, which is at least partially useless, because I > can't use it together with boost libraries that require linking. > > Now that surprises me... It shouldn't. But if the default was to build boost for both single and MT, would that take away the surprise? /ikh </previous> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
