On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert
On 5/04/2015 08:00, Niall Douglas wrote:
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old). BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table): http://store.steampowered.com/hwsurvey/ Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick. So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.