Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Boris Rasin (boris_at_[hidden])
Date: 2016-03-08 02:36:42
On 2016-03-08 6:18 AM, Rene Rivera wrote:
> 1. Some people don't fancy auto-linking.
> 2. People responding with "+N".. Which of the following would you prefer?
> And give rationale for your preference, and optionally give rationales for
> not preferring others:
> A) Having file names with "32" *and* "64" on them?
> B) Having current names indicate 32 and adding "64" to file names otherwise?
> C) Having current names indicate the "default" system address-model and add
> "32" or "64" to indicate the non-default?
> D) Having the current names and placing 32 bit address-model variants in
> "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install
> E) Having the current names and placing 32 bit address-model variants in
> "stage/lib" and 64 bit in "stage/lib64"? (Equivalently for install location)
> F) Having the current names and placing the "default" system address-model
> variants in "stage/lib" and the non-default in "stage/lib32" or
> "stage/lib64"? (Equivalently for install location)
I would prefer option A. It fits current naming scheme where each
is spelled out explicitly as part of the name: toolset, thread_opt,
rt_opt. This would
just add another option to this list: platform(x86, x64, arm).
There is another alternative, which will suit better people who don't
use the composed name for folder and keep library names the same:
Auto-linking would work exactly as it works now, but for people
configuring projects manually
things will become much easier: specify the same library names for all
targets, just a different
folder to look for libraries per each target.
This would become even better if option names were to correspond to
relevant toolset macro names.
Than one could also specify the same lib folder for all targets:
This would expand into:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk