Build breaking changes

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Build breaking changes

Boost - Dev mailing list
Hello,

I've just noted that building Boost from master stopped working:

[00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release
architecture=x86 link=static --with-program_options --with-filesystem
--with-system --with-test --with-atomic --with-thread --with-timer
--with-date_time --with-chrono --with-regex --with-random
--with-context stage

[00:16:52] Performing configuration checks
[00:16:52]
[00:16:52]     - default address-model    : 32-bit
[00:16:53]     - default architecture     : x86
[00:16:53]     - symlinks supported       : yes (cached)
[00:16:54]     - C++11 mutex              : yes
[00:16:55]     - has_icu builds           : no
[00:16:55]     - BOOST_COMP_GNUC >= 4.3.0 : yes
[00:16:55]     - C++11 mutex              : no
[00:16:56]     - has_icu builds           : no
[00:16:56]     - BOOST_COMP_GNUC >= 4.3.0 : no
[00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a'
[00:16:56] error:
[00:16:56] error: Tried to build the target twice, with property sets having
[00:16:56] error: these incompatible properties:
[00:16:56] error:
[00:16:56] error:     -  <address-model>64
[00:16:56] error:     -  <address-model>32
[00:16:56] error:
[00:16:56] error: Please make sure to have consistent requirements for these
[00:16:56] error: properties everywhere in your project, especially for install
[00:16:56] error: targets.
[00:16:56]
[00:16:56] Command exited with code 1


Previously this build command worked fine. Full log available at
https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_edition/job/y9tsbgi430280u7y


Is this an intended breaking change?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
AMDG

On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
>
> I've just noted that building Boost from master stopped working:
>
> [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release
> architecture=x86 link=static --with-program_options --with-filesystem
> --with-system --with-test --with-atomic --with-thread --with-timer
> --with-date_time --with-chrono --with-regex --with-random
> --with-context stage
>

  The change was to build both 32-bit and 64-bit libraries
by default on windows.  Building multiple variants conflicts
with --layout=system.  You can work around this by
explicitly adding address-model=64.  Perhaps we need
to adjust the default variant(s) based on the value of
--layout.

> [00:16:52] Performing configuration checks
> [00:16:52]
> [00:16:52]     - default address-model    : 32-bit
> [00:16:53]     - default architecture     : x86
> [00:16:53]     - symlinks supported       : yes (cached)
> [00:16:54]     - C++11 mutex              : yes
> [00:16:55]     - has_icu builds           : no
> [00:16:55]     - BOOST_COMP_GNUC >= 4.3.0 : yes
> [00:16:55]     - C++11 mutex              : no
> [00:16:56]     - has_icu builds           : no
> [00:16:56]     - BOOST_COMP_GNUC >= 4.3.0 : no
> [00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a'
> [00:16:56] error:
> [00:16:56] error: Tried to build the target twice, with property sets having
> [00:16:56] error: these incompatible properties:
> [00:16:56] error:
> [00:16:56] error:     -  <address-model>64
> [00:16:56] error:     -  <address-model>32
> [00:16:56] error:
> [00:16:56] error: Please make sure to have consistent requirements for these
> [00:16:56] error: properties everywhere in your project, especially for install
> [00:16:56] error: targets.
> [00:16:56]
> [00:16:56] Command exited with code 1
>
>
> Previously this build command worked fine. Full log available at
> https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_edition/job/y9tsbgi430280u7y
>
>
> Is this an intended breaking change?
>
In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 03/29/18 00:07, Steven Watanabe via Boost wrote:

> AMDG
>
> On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
>>
>> I've just noted that building Boost from master stopped working:
>>
>> [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release
>> architecture=x86 link=static --with-program_options --with-filesystem
>> --with-system --with-test --with-atomic --with-thread --with-timer
>> --with-date_time --with-chrono --with-regex --with-random
>> --with-context stage
>>
>
>    The change was to build both 32-bit and 64-bit libraries
> by default on windows.  Building multiple variants conflicts
> with --layout=system.  You can work around this by
> explicitly adding address-model=64.  Perhaps we need
> to adjust the default variant(s) based on the value of
> --layout.

Maybe we should just change the default to address-model=64. Really,
32-bit x86 is long long outdated.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 29/03/2018 10:47, Andrey Semashev wrote:
> Maybe we should just change the default to address-model=64. Really,
> 32-bit x86 is long long outdated.

While 64-bit OSes are the norm (and on Linux this also applies to
applications that are built from source, which is most of them), on
Windows and outside of spaces that require large amounts of memory (such
as games and graphics) it is still more common to have 32-bit apps than
64-bit ones.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 03/29/18 02:52, Gavin Lambert via Boost wrote:
> On 29/03/2018 10:47, Andrey Semashev wrote:
>> Maybe we should just change the default to address-model=64. Really,
>> 32-bit x86 is long long outdated.
>
> While 64-bit OSes are the norm (and on Linux this also applies to
> applications that are built from source, which is most of them), on
> Windows and outside of spaces that require large amounts of memory (such
> as games and graphics) it is still more common to have 32-bit apps than
> 64-bit ones.

Most of applications have 32 and 64-bit variants, unless they stuck in
the 90's. Defaulting nowdays to 32 bits is simply unreasonable. If
someone wants to target an outdated architecture (and 32-bit x86 really
is a separate architecture, including hardware features and software
ABI) then let them do that with a little more effort. The rest of the
world have moved to 64 bits long ago, and that is what we should target
by default, IMO.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 29/03/2018 13:49, Andrey Semashev wrote:
> Most of applications have 32 and 64-bit variants, unless they stuck in
> the 90's. Defaulting nowdays to 32 bits is simply unreasonable.

Boost doesn't default to 32 bits.  It defaults to both 32 and 64, which
is the most reasonable choice on Windows, just as defaulting to the host
architecture is the most reasonable choice on Linux.

Visual Studio always defaults to 32-bits, thus most Windows applications
do as well.

Even pure .NET projects, which are compiled to IL and can run equally
well as 32-bit or 64-bit, have the "prefer 32-bit" flag set by default
which means that they will run as 32-bit if given the option (ie. not
loaded as a DLL into a process that is already 64-bit).

Take any random Windows machine and run a lot of applications on it.
Now look at Task Manager and see how many of those applications have (32
bit) next to them.  If you exclude OS-in-box components, games, CAD
packages, and the like, you will almost certainly find that your number
is higher than 90%.  (Heck, until very recently most web browsers were
also 32-bit-only, and they do fall into the category of apps that
benefit from 64-bit.)

Perhaps this is not your ideal world.  And I agree that x86-32 is indeed
a different (and inferior) architecture from amd64.  But being different
is in and of itself one reason why apps don't change architectures
unless they actually need to (since the rules are subtly different, and
it's another thing to test), and the vast majority of apps don't
actually need to.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost
<[hidden email]> wrote:
> If someone wants to target an outdated architecture (and 32-bit x86 really is
> a separate architecture, including hardware features and software ABI) then
> let them do that with a little more effort. The rest of the world have moved to 64 bits
> long ago, and that is what we should target by default, IMO.

No they have not all "moved on to 64 bits." Most programs work
perfectly fine as 32-bit applications and have no need for the ability
to access a full 64-bit address space. In fact many programs perform
objectively worse as 64-bit application since pointers and data
structures become larger without a corresponding benefit. This is
especially true for mobile applications.

Rumors of 32-bit apps' demise are greatly exaggerated.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 28, 2018 at 11:47 PM, Andrey Semashev via Boost
<[hidden email]> wrote:

> On 03/29/18 00:07, Steven Watanabe via Boost wrote:
>>
>> AMDG
>>
>> On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
>>>
>>>
>>> I've just noted that building Boost from master stopped working:
>>>
>>> [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release
>>> architecture=x86 link=static --with-program_options --with-filesystem
>>> --with-system --with-test --with-atomic --with-thread --with-timer
>>> --with-date_time --with-chrono --with-regex --with-random
>>> --with-context stage
>>>
>>
>>    The change was to build both 32-bit and 64-bit libraries
>> by default on windows.  Building multiple variants conflicts
>> with --layout=system.  You can work around this by
>> explicitly adding address-model=64.  Perhaps we need
>> to adjust the default variant(s) based on the value of
>> --layout.
>
>
> Maybe we should just change the default to address-model=64. Really, 32-bit
> x86 is long long outdated.

Repeating the same thing over and over doesn't make it true.


--
Olaf

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/29/18 05:51, Vinnie Falco via Boost wrote:

> On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost
> <[hidden email]> wrote:
>> If someone wants to target an outdated architecture (and 32-bit x86 really is
>> a separate architecture, including hardware features and software ABI) then
>> let them do that with a little more effort. The rest of the world have moved to 64 bits
>> long ago, and that is what we should target by default, IMO.
>
> No they have not all "moved on to 64 bits." Most programs work
> perfectly fine as 32-bit applications and have no need for the ability
> to access a full 64-bit address space. In fact many programs perform
> objectively worse as 64-bit application since pointers and data
> structures become larger without a corresponding benefit. This is
> especially true for mobile applications.

Memory is cheap and the increase from the pointer size is not
significant[1]. Although x86 is not really relevant in that area, even
mainstream smartphones now have 3+ GiB of RAM. Laptops come with more
than 4. The x32[2] initiative didn't really take off[3] because the
benefits from reducing pointers to 32 bits are not significant enough.

I really don't understand why people cling to the old x86 while the bits
of silicon and associated performance lie wasted in their CPUs.

[1]: https://youtu.be/nLOXwRhOhWY?t=410 - before that time there are
performance comparisons
[2]: https://en.wikipedia.org/wiki/X32_ABI
[3]: https://www.phoronix.com/scan.php?page=news_item&px=MTU1MjE

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/29/18 10:27, Olaf van der Spek wrote:
> On Wed, Mar 28, 2018 at 11:47 PM, Andrey Semashev via Boost
> <[hidden email]> wrote:
>>
>> Maybe we should just change the default to address-model=64. Really, 32-bit
>> x86 is long long outdated.
>
> Repeating the same thing over and over doesn't make it true.

Are you trying to say 32-bit x86 is not outdated?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Mar 28, 2018, 10:51 PM Vinnie Falco via Boost <[hidden email]>
wrote:

> On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost
> <[hidden email]> wrote:
> > If someone wants to target an outdated architecture (and 32-bit x86
> really is
> > a separate architecture, including hardware features and software ABI)
> then
> > let them do that with a little more effort. The rest of the world have
> moved to 64 bits
> > long ago, and that is what we should target by default, IMO.
>
> No they have not all "moved on to 64 bits." Most programs work
> perfectly fine as 32-bit applications and have no need for the ability
> to access a full 64-bit address space. In fact many programs perform
> objectively worse as 64-bit application since pointers and data
> structures become larger without a corresponding benefit. This is
> especially true for mobile applications.
>
> Rumors of 32-bit apps' demise are greatly exaggerated.
>

The corresponding benefit is access to twice as many CPU registers (on
amd64, anyway) which provides a notable performance benefit to many
applications (given a compiler outputting code that leverages it).  I don't
know if the same can be said for other 64-bit architectures.  amd64 was
released in 2000.  The debian project reported that in 2012, downloads of
the x86_64 architecture surpassed the x86 architecture.  The addition of
the NX bit is a security improvement in amd64 that x86 cannot leverage, and
given what we've seen recently, CPU enforced security (and correctness) is
pretty important.  We're not saying that we won't support 32-bit, however
if someone just says "b2" on an x86 based platform it should default to an
address-model of 64 unless otherwise overridden.

- Jim

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
James E. King, III wrote:

> The debian project reported that in 2012, downloads of the x86_64
> architecture surpassed the x86 architecture.

This (a) doesn't have anything to do with Windows and (b) relates to the
architecture of the OS rather than the code running on it. Most Windows
installations are 64 bit. Most code running on Windows is still 32 bit,
although this is changing.

> The addition of the NX bit is a security improvement in amd64 that x86
> cannot leverage,

I think that 32 bit code under Windows 64 does leverage the NX bit, but I'm
too lazy to check.

Either way, this thread was not originally about the default address-model.
It was about what was built by default for `b2 --build-type=minimal` (which
is the default). Under Linux, this builds the default address-model, which
is 64 bit on a 64 bit OS. Under Windows, it used to build 32 bit, and I
changed it to build both 32 and 64 bit.

The reason it built 32 bit was that build-type=minimal on Windows built
whatever were the default project settings in a new Visual Studio project,
to make it easier for people trying out Boost to have the project autolink
correctly.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/28/2018 9:51 PM, Vinnie Falco via Boost wrote:

> On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost
> <[hidden email]> wrote:
>> If someone wants to target an outdated architecture (and 32-bit x86 really is
>> a separate architecture, including hardware features and software ABI) then
>> let them do that with a little more effort. The rest of the world have moved to 64 bits
>> long ago, and that is what we should target by default, IMO.
>
> No they have not all "moved on to 64 bits." Most programs work
> perfectly fine as 32-bit applications and have no need for the ability
> to access a full 64-bit address space. In fact many programs perform
> objectively worse as 64-bit application since pointers and data
> structures become larger without a corresponding benefit. This is
> especially true for mobile applications.

Note that the Visual Studio 2017 default for all new projects/solutions
is 32-bit, x86 (aka Win32).  In older Visual Studio releases, extra
mouse clicks are required to configure a project to compile as x64.  If
there are a family of projects within an existing solution, then all
projects individual project files will likely have to be manually edited
to support x64.  Ask me how I know.

Also note that until proven otherwise, the Boost Unit Test Adapter fork
by Microsoft only integrates with Visual Studio 2017 correctly when set
to x86 | Release.  No other configuration setting will run within the
IDE, let alone integrate correctly with the Visual Studio 2017
environment.  When this is finally fixed, I have no idea.  You will have
to ask the Microsoft team managing the Boost Unit Test Adapter fork.

>
> Rumors of 32-bit apps' demise are greatly exaggerated.
Seconded

--Robert

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Mar 29, 2018, 16:51 Peter Dimov via Boost <[hidden email]>
wrote:

> Either way, this thread was not originally about the default address-model.
> It was about what was built by default for `b2 --build-type=minimal` (which
> is the default). Under Linux, this builds the default address-model, which
> is 64 bit on a 64 bit OS. Under Windows, it used to build 32 bit, and I
> changed it to build both 32 and 64 bit.
>

Some MinGW do not support 64 bit builds at all (here's an example
https://ci.appveyor.com/project/apolukhin/boost-cookbook/build/1.65.130-second_edition/job/9o0t8f1o2s5drdue
)

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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 03/29/18 18:17, Robert via Boost wrote:

>
> Note that the Visual Studio 2017 default for all new projects/solutions
> is 32-bit, x86 (aka Win32).  In older Visual Studio releases, extra
> mouse clicks are required to configure a project to compile as x64.  If
> there are a family of projects within an existing solution, then all
> projects individual project files will likely have to be manually edited
> to support x64.  Ask me how I know.
>
> Also note that until proven otherwise, the Boost Unit Test Adapter fork
> by Microsoft only integrates with Visual Studio 2017 correctly when set
> to x86 | Release.  No other configuration setting will run within the
> IDE, let alone integrate correctly with the Visual Studio 2017
> environment.  When this is finally fixed, I have no idea.  You will have
> to ask the Microsoft team managing the Boost Unit Test Adapter fork.

Difficulty with one particular IDE does not count as a valid reason to
stick with 32-bit x86 to me.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 3/29/2018 1:48 PM, Andrey Semashev via Boost wrote:

> On 03/29/18 18:17, Robert via Boost wrote:
>>
>> Note that the Visual Studio 2017 default for all new
>> projects/solutions is 32-bit, x86 (aka Win32).  In older Visual Studio
>> releases, extra mouse clicks are required to configure a project to
>> compile as x64.  If there are a family of projects within an existing
>> solution, then all projects individual project files will likely have
>> to be manually edited to support x64.  Ask me how I know.
>>
>> Also note that until proven otherwise, the Boost Unit Test Adapter
>> fork by Microsoft only integrates with Visual Studio 2017 correctly
>> when set to x86 | Release.  No other configuration setting will run
>> within the IDE, let alone integrate correctly with the Visual Studio
>> 2017 environment.  When this is finally fixed, I have no idea.  You
>> will have to ask the Microsoft team managing the Boost Unit Test
>> Adapter fork.
>
> Difficulty with one particular IDE does not count as a valid reason to
> stick with 32-bit x86 to me.

Agreed.  My purpose posting the above is so the rest of us know about
the environment defaults.  Where I work, we are currently supporting
both 32-bit and 64-bit product releases.  We do so because of our
customer base use cases.

--Robert

>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 29 March 2018 at 19:00, Antony Polukhin via Boost <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
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 <[hidden email]> On Behalf Of Klaim - Joël
> Lamotte via Boost
> Sent: Thursday, March 29, 2018 11:17 PM
> To: Boost Developers List <[hidden email]>
> Cc: Klaim - Joël Lamotte <[hidden email]>; Peter Dimov
> <[hidden email]>
> Subject: Re: [boost] Build breaking changes
>
> On 29 March 2018 at 19:00, Antony Polukhin via Boost
> <[hidden email]>
> 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 30/03/2018 07:48, Andrey Semashev wrote:
> Difficulty with one particular IDE does not count as a valid reason to
> stick with 32-bit x86 to me.

While the above is true, having the most popular compiler and IDE of the
platform default to 32-bit does argue very strongly to *not stop*
building 32-bit by default _on Windows_.

Thus I stand by what I said before -- building both 32 and 64 is the
best default choice for VC++ binaries on Windows.  For mingw64 and
Linux, other default choices may make more sense.

If others prefer that the default should only ever to be to compile one
address-model (which is not my preference), then the default for Windows
should be 32, not 64.  Because while it might be older and does have
some deficiencies, it is *still* the default for the platform as a
whole.  (This is independent of the OS architecture itself.)

So, at least for Windows, as a default, in my opinion: 32+64 > 32 > 64.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: Build breaking changes

Boost - Dev mailing list
On 2 April 2018 at 20:30, Gavin Lambert via Boost <[hidden email]>
wrote:

> On 30/03/2018 07:48, Andrey Semashev wrote:
>
>> Difficulty with one particular IDE does not count as a valid reason to
>> stick with 32-bit x86 to me.
>>
>
> While the above is true, having the most popular compiler and IDE of the
> platform default to 32-bit does argue very strongly to *not stop* building
> 32-bit by default _on Windows_.
>

This might not stay this way! It also departs from the assumption that
*all* VS users are total numwitz, and do not attempt and succeed to set up
and select a 64-bit project.

degski

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12