Re: [boost] Build breaking changes

Subject: Re: [boost] Build breaking changes
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2018-03-29 21:16:43

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