Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-04-27 20:33:36
On 25/04/2015 21:18, Paul A. Bristow wrote:
>> The minimum acceptable standard would be for
>> b2 address-model=32,64 stage
>> to work under Windows. Whether this is done via separate
>> directories or separate names is up to us; so far people
>> seem to prefer separate directories, but either way is
>> good enough.
>> Typically, separate directories are more convenient
>> because one only needs to change the library path
>> to switch between 32/64;
>> separate names however are more convenient when
>> autolinking, in which case nothing needs to
>> change, and we already encode build settings into the
>> name on Windows.
> Autolinking is *very* convenient and would be badly missed.
> If and how does autolinking work with separate directories ?
Autolinking should work fine either way.
1. Boost library names are not changed, but 32-bit and 64-bit binaries
are built to separate dirs (either the current dir for 32-bit and an x64
subdir for 64-bit, or separate subdirs for each -- that's an
ease-of-migration question that'll get bikeshedded).
In this case it is the library user's responsibility to point at the
correct library dir depending whether their project is 32-bit or 64-bit;
the auto-linking code in Boost does not change at all and as long as
only the "right" dir is in the library paths (and installed with the
application, if a DLL) then it will find the right binary.
(This option is probably the easiest on applications that specifically
choose to target one or the other; but it might be annoying where the
build system or something else decides the platform or the same project
files are used for both platforms.)
2. Boost library names are changed to include 32/64-bit and the binaries
are built to the same dir. In this case the autolinking code needs to
be updated to match the new library names, but otherwise everything Just
Works. The user doesn't have to update their project files at all, but
they might have to update their application install scripts for the new
(This is probably the easiest on people who use auto-linking on Windows,
but might annoy Linux packagers if the same naming conventions are
brought there too, since they don't like having the architecture in the
3. Boost library names are changed to include 32/64-bit *and* the
binaries are built to different dirs. This combines both caveats of the
above without any additional benefit, AFAIK.