Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection

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.

Either:

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 
library names.

(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 
package name.)

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.