I think the problem here is that we have two options for the <threading> variant, but really we should have three:
1) threading must be on 2) threading must be off 3) whatever the default is for the compiler
Most people actually want option (3) a lot of the time,
Actually, I just don't want to pay for MT, unless I really mean to use the code in MT environment.
and currently that's what <threading>single more or less gives you, ideally though we would map builds for option 3 to either 1 or 2 so we don't build
I understand that, but we have to decide how to handle this, so that it is actualy safe, and in particular boost headers should honor the compilers default setting. libraries
we've actually already built.
I don't really understand the problem. For example, are there any compilers which generate MT code by default? And, what's "default for the compiler"?
Yes, lots of them, MSVC when using a dll runtime, some Unix compilers I believe (though I forget which ones, can probably find out if it's important), gcc on some platforms as well. Actually with gcc you already "pay" for threading support in the standard lib, likewise with MSVC, if you really want it turned off in Boost, then defining BOOST_DISABLE_THREADS will do the trick. What I'm trying to say is that our default behaviour should be the same as the compiler and std lib in use, any thing else will lead to confusion IMO.
This happens at the moment for example with MSVC where <runtime-link>dynamic implies <threading>multi, and any other option for the <threading> variant gets ignored.
And what's the problem with that?
You build the same library twice - for example with MSVC the <threading>multi<runtime-link>dynamic and <threading>single<runtime-link>dynamic variants are the actually the same thing (as far as the binaries are concerned), but both get built separately by a Boost install. John.