Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-04-07 02:38:59

On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <gavinl_at_[hidden]> wrote:
> 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.