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.