On 11/08/2015 16:55, Andrey Semashev wrote:
I can understand the current Boost.Build behavior though. Normally you build binaries for the same architecture the build tool is built for, which is 32-bit x86 in case of 32-bit bjam. When you build for another architecture, like amd64, this is a cross build, and it is logical to use a cross-compiler for that.
On Linux, yes; things are a bit murkier on Windows. On Linux it's common that installing the 64-bit variant will result in almost all installed software also being 64-bit. As a result it's reasonably safe (though not foolproof) to assume that whatever is running is the native architecture. On Windows it's still common for almost all software installed to be 32-bit regardless of whether the OS itself is 32-bit or 64-bit, and the OS is quite good at pretending the world is 32-bit when running a 32-bit app, for backwards compatibility reasons. The Visual Studio IDE itself is 32-bit, regardless of whether it runs the x86 or the amd64 native compilers, or some cross-compiler. Generally Windows software only gets a 64-bit flavour if it needs to integrate with something in the OS (eg. shell extensions, drivers) or if it's expecting high memory usage.
I wonder if we should be building a 64-bit bjam on a 64-bit Windows by default though. It's not a change for 1.59 but still worth considering for future releases.
That would be another way to solve it, yes. Although then the question would be whether it should use the native x86 compiler or the amd64_x86 cross-compiler. (It is actually possible in some Windows versions to remove the ability to run 32-bit code, although I would be quite surprised if anyone actually does that, especially in a development environment.) Note that currently a 64-bit bjam *won't* use the cross-compiler; I think it just operates on a "by default we're running x86" assumption rather than trying to follow the native architecture like you suggested above. Comments near the code I patched seem to support this. :)