On 15/10/2017 23:43, Peter Dimov wrote:

...

I've just merged https://github.com/boostorg/boost/pull/149, "Encode architecture and address model in versioned layout names", into the develop branch. Let's see how this goes.

Welcome to 2005. :-)

Sounds good :)

Now that building Boost with address-model=32,64 works, I think that we ought to build both for --build-type=complete on Windows.

I'm less sure about --build-type=minimal, but given that (a) what minimal builds is determined by the configuration Visual Studio projects use by default (which is 32 bit) and (b) that we're getting more and more calls for 64 being built by default, it looks like --build-type=minimal ought to build both 32 and 64 as well. I'm less sure about that too. It's probably still true that the majority of Windows applications are 32-bit only (there's not really any need to build a 64-bit app unless you need >2GB of RAM or are writing a

Also sounds good. plugin for something that is already 64-bit). It might annoy these people if a "minimal" build builds a "useless" 64-bit library. But if one is significantly easier to implement than the other... On the third hand, what makes sense for Linux (or not-Windows in general)? I presume building only the native architecture makes the most sense there, even for --build-type=complete, since many installations wouldn't even have both. What then for POSIX-within-Windows, like Mingw64? Does different default behaviour (and thus possibly different recommended build command lines) between Windows and not-Windows bother anyone? Since some Linux distros are multi-arch (mainly dual 32/64, although more esoteric combinations are also possible), should it similarly try to build for both/all on those too? (I did briefly ponder the idea of adding another build type, but couldn't come up with a compelling motivation over just using address-model explicitly.)

On 16 October 2017 at 12:41, Olaf van der Spek via Boost < boost@lists.boost.org> wrote:

4GB.. if you enable LargeAddressAware

Another reason to have 64-bit would be to use multi-precision, or any avx-instructions. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On Sun, Oct 15, 2017 at 12:43 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

...

I've just merged https://github.com/boostorg/boost/pull/149, "Encode architecture and address model in versioned layout names", into the develop branch. Let's see how this goes.

Welcome to 2005. :-)

Now that building Boost with address-model=32,64 works, I think that we ought to build both for --build-type=complete on Windows. I'm less sure about --build-type=minimal, but given that (a) what minimal builds is determined by the configuration Visual Studio projects use by default (which is 32 bit) and (b) that we're getting more and more calls for 64 being built by default, it looks like --build-type=minimal ought to build both 32 and 64 as well.

that we're getting more and more calls for 64 being built by default,

By default, does that mean with or without --build-type=complete specified? -- Olaf

On Mon, Oct 16, 2017 at 2:04 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

Olaf van der Spek wrote:

...

...

Now that building Boost with address-model=32,64 works, I think that we

...

ought to build both for --build-type=complete on Windows. I'm less sure > about --build-type=minimal, but given that (a) what minimal builds is > determined by the configuration Visual Studio projects use by default > (which is 32 bit) and (b) that we're getting more and more calls for 64 > being built by default, it looks like --build-type=minimal ought to > build both 32 and 64 as well.

...

that we're getting more and more calls for 64 being built by default,

By default, does that mean with or without --build-type=complete specified?

Without.

So would the default build-type be changed to complete or would a new build-type be introduced for this? Having complete be the default would be most convenient, with minimal allowing you to optimize for space. -- Olaf

Am 17.10.2017 um 11:26 schrieb Paul A. Bristow via Boost:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek via Boost Sent: 16 October 2017 18:33 To: boost@lists.boost.org Cc: Olaf van der Spek; Peter Dimov Subject: Re: [boost] Merged #149, "Encode architecture and address model in versioned layout names"

On Mon, Oct 16, 2017 at 2:04 PM, Peter Dimov via Boost <boost@lists.boost.org> wrote:

...

Olaf van der Spek wrote:

...

...

Now that building Boost with address-model=32,64 works, I think that we

...

ought to build both for --build-type=complete on Windows. I'm less sure > about --build-type=minimal, but given that (a) what minimal builds is > determined by the configuration Visual Studio projects use by default > (which is 32 bit) and (b) that we're getting more and more calls for 64 > being built by default, it looks like --build-type=minimal ought to > build both 32 and 64 as well.

...

that we're getting more and more calls for 64 being built by default,

By default, does that mean with or without --build-type=complete specified?

Without.

So would the default build-type be changed to complete or would a new build-type be introduced for this?

Having complete be the default would be most convenient, with minimal allowing you to optimize for space.

There are many novice 'missing library version cries for help' that could be avoided by ensuring that all library versions are built by default.

Then, additionally, the issue regarding incomplete compiler-tag (reported here [1]) should probably be fixed, too.

So +1 for complete 64 and 32 bit.

The cognoscenti can and will easily use a command that cuts to their minimum.

[1] https://github.com/boostorg/build/issues/191 Best regards, Deniz