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