Anthony Williams wrote:
I am not sure what we can do about this. One issue is that currently the thread lib requires windows.h, and therefore compiler extensions, when the library sources are built. I'm not sure whether it is safe to link something compiled with extensions on against something compiled with extensions off --- is the ABI the same?
I am pretty much sure it is. Otherwise it would be impossible to link a library, which even might be produced by a compiler of a different laguage.
If it *is* safe, then we should remove this define from boost/config/suffix.hpp, since the boost thread headers don't explicitly include windows.h.
Hmm, true for the current version, but if we go header only in future?
OTOH, someone put the restriction there for a reason, and I wouldn't want to remove it without careful thought.
I always thought it was a bad idea for the Boost.Thread to explicitly depend on these macros when invoked from client builds. If you look into my platform split of the thread_rewrite branch you will see, that I have tried to not rely on these, and as it turns out now this is a good thing. (Altough it does not go yet all the way, just pointing the direction.) The client code might be interested which threading API is available _if_ it is going to make use of it. If Boost.Thread is being used the client code needs not know (and should be able to compile without language extensions). Another issue is the semantics of BOOST_HAS_THREADS: Does it mean 1) No OS threading API available or 2) No threading at all ? I currently see it as 1). You still should be able to use Boost.Thread. Then when client code defines: BOOST_DISABLE_THREADS the implementation of Boost.Thread could make use of this information and replace everything that makes sense with stubs. It does not make sense to stub out the thread launching API, but it makes sense for the locking API. Thread launching should give a compile error in this case. This would allow library users to write MT aware library code without #idefing when used in a single thread context. All this does not help much in the current implementation, and I would not attempt to change any of these short before release. But we definitely should do it for the next release! Sorry for my whining, but I have to reiterate: We should _not_ try to do as much as possible header only. This issue is just another bullet on my list why we should not. I agree there are lot of things which require header only, but we should try to do as much as possible using the library mechanism. Roland