Re: [boost] Build breaking changes

Subject: Re: [boost] Build breaking changes
From: mike.dev_at_[hidden]
Date: 2018-03-31 14:11:53

My personal Preference as a Boost user on Windows:

- The binary distribution should definitely contain 32 and 64 bit builds - most serious projects need both anyway.
- The default build should only compile one version (my preference would be x64) to reduce compilation times.
- There needs to be good, prominent documentation that shows, how to select the versions that are going to be built (maybe as part of https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html)

For any serious deployment it is very likely that people will either use the binary distribution, which should work for as many scenarios as possible, or - when they build themselves - will configure boost according to their specific needs anyway.
However, for experimentation / initial testing of patches aso., short build-times are more important and one address model is usually enough. This is also the scenario, where defaults are imho most important.

Personally I'm using x64 for anything where I don't have an explicit requirement to support 32 bit which is the reason for my x64 default preference (and I think/hope it will become the default on windows sooner or later anyway), but isn't so important to me.

Best
Mike

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Klaim - Joël
> Lamotte via Boost
> Sent: Thursday, March 29, 2018 11:17 PM
> To: Boost Developers List <boost_at_[hidden]>
> Cc: Klaim - Joël Lamotte <mjklaim_at_[hidden]>; Peter Dimov
> <lists_at_[hidden]>
> Subject: Re: [boost] Build breaking changes
> 
> On 29 March 2018 at 19:00, Antony Polukhin via Boost
> <boost_at_[hidden]>
> wrote:
> 
> >
> > IMO a good solution for this issue would be to test for an ability of the
> > compiler to do 64bit builds. If it does not support 64 bit builds - just
> > disable them and build i  32 bit mode.
> >
> > About 32 or 64 bits by default... I'd prefer 64 bits as a more modern
> > solution. Users always can switch back to 32 if they have a need.
> >
> >
> My small data point, as a boost user and cross platform dev. In all of my
> applications I need:
>  - both 32bit and 64bit versions of boost on windows and linux (embedded
> 32bit)
>  - to generate both 32bit and 64bit versions of my apps
> because
>  - experience shows (because of different possible reasons, including
> cache
> miss profile changes)
>      that guessing which one will be the most efficient is not possible, so
> depending on the app, I/we decide to use one or the other.
>  - for some programs I need to use some closed libraries (unfortunately I
> can't easily change that now) which only provide 32bit binaries,
>    but I still need a different 64bit version available too (without these
> libs but without the related features too);
>  - "memory is cheap" is actually wrong when your main performance
> bottleneck is cache-misses that trigger more in 64bit because your structs
> containing pointers just double sizes;
>  - also note that the size of binaries (that 64bit often impacts) is a
> major issue with some online systems when updating as it can lead to
> significant downloads, even with
>      a binary patching system;
> 
> My point: it's not obvious at all which of 32bit or 64bit is superior in
> practice (at least on windows but not clear if it's an OS thing or not)
> depending on the application and how it's coded,
>   although it would make my life easier if 64bit was not surprisingly
> expensive sometime, so that I don't have to bother about that (and
> sometime
> I just ignore the hit and use it anyway, depends).
> 
> All that is not very important actually if I was just building boost with
> the right flags to compile all I need - which is basically what I do anyway.
> 
> The core issue that lead to that change, if my memory is correct, is that
> the boost binaries distribution, which is equivalent to the default build
> configuration,
> have to be set so that tools (in particular CMake) have a change to guess
> which version is built (which is now in the file name)
> and select the version depending on what the user want (instead of having
> to point to different boost install directories manually).
> Next CMake version will handle boost binaries detection automatically (the
> patch have been merged several weeks ago,  I dont know why it was not in
> the last release but they plan it for the next).
> 
> Though it forces me to adapt my boost build scripts to build all variants,
> I'm not against the default build config to only building one of the
> platforms (but please keep the tests running for both! both are used!).
> It also seem ok if it's only 64bit by default.
> 
> However, please keep the new naming layout as it is to make sure tools
> identify the architecture of the binaries easily and the binary distribution
> matches at least partially a default build of boost. As long as you keep
> that, it should be fine IMO (although keep in
> mind that 32bit dev will not go away on Windows soon, it really is
> unfortunately necessary to be able to use it depending on the program).
> 
> A. Joël Lamotte
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost