Re: [boost] 32/64 library name conflict under Windows?

Subject: Re: [boost] 32/64 library name conflict under Windows?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2016-03-08 05:45:51

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Rene Rivera
> Sent: 08 March 2016 04:19
> To: boost_at_[hidden]
> Subject: Re: [boost] 32/64 library name conflict under Windows?
> 
> On Fri, Mar 4, 2016 at 12:31 PM, Peter Dimov <lists_at_[hidden]> wrote:
> 
> > I remember that we discussed this problem before:
> >
> > C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0
> > address-model=32,64
> >
> > [...]
> >
> > error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib'
> > error:
> > error: Tried to build the target twice, with property sets having
> > error: these incompatible properties:
> > error:
> > error:     -  <address-model>32
> > error:     -  <address-model>64
> > error:
> > error: Please make sure to have consistent requirements for these
> > error: properties everywhere in your project, especially for install
> > error: targets.
> >
> > but don't remember what we concluded. Will we support building both 32 and
> > 64 bit libraries under Windows? At present if I want to have an IDE project
> > that has both Win32 and x64 configurations I need to build the 32 bit
> > libraries, move them out of stage/lib somewhere, then build the 64 bit
> > libraries, then move them out of stage/lib to somewhere else, and set my
> > library directories in the IDE accordingly.
> >
> > It would be much more convenient if 32/64 were encoded into the name, so
> > that I can leave my library path to point at stage/lib and rely on autolink
> > to choose the right .lib file automatically, like it works today for the
> > other options (debug/release, static/dynamic runtime).
> >
> 
> 1. Some people don't fancy auto-linking.

Excellent (when it works - almost always).
 
> 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?

Explicit is good.  

Follows current scheme of having different unique names for different variants.
Once started unique names, we should continue.
 
> B) Having current names indicate 32 and adding "64" to file names otherwise?

Acceptable.

> C) Having current names indicate the "default" system address-model and add
> "32" or "64" to indicate the non-default?

KISS
 
> D) Having the current names and placing 32 bit address-model variants in
> "stage/lib32" and 64 bit in "stage/lib64"? (Equivalently for install location)

Having two files with same name in different folders is less explicit than two different filenames. 

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

Make be less trouble short term, but less clear when 64 becomes the default?

(and what about 128-bit ;-)

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

KISS (https://en.wikipedia.org/wiki/KISS_principle  is *my* default position).

So I favour option A.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]