John Maddock wrote:
There may still be issues with BOOST_DISABLE_WIN32 causing binary incompatibity between object files compiled with and without it (I think it might with regex, but haven't fully checked).
The problem is we've never really supported this: it's always been a "use the same options everywhere" policy.
True. But the problem here is that this is a legitimate scenario for not using the same options everywhere. Typically, when protability is desired, all code that uses <windows.h> is isolated into a translation unit or two, and the rest of the code base is compiled with /Za. So the fact that <windows.h> will not compile is a feature in this case; it shows people that someone has introduced a Windows dependency in the portable code. We can't support this scenario if our libraries test for /Za and do something different because of ODR violations. We can leave BOOST_DISABLE_WIN32 as a user macro and not have the config system set it. Or we can just make the libraries not test for BOOST_DISABLE_WIN32, if that's feasible. Since bjam doesn't set /Za, they will build fine; as long as they don't include <windows.h> in their headers, and they must never do so, they will be usable with or without /Za. I think.