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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk