Re: [boost] Merged #149, "Encode architecture and address model in versioned layout names"

Subject: Re: [boost] Merged #149, "Encode architecture and address model in versioned layout names"
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-10-16 07:17:24

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.

Also sounds good.

> 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 
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.)